Stačí htmlspecialchars() jako ochrana proti SQL Injection?

Str4wberry:
„Bezpečnostní risiko představuje na druhou stranu i ukládání surových dat, když se někde zapomene na ošetření při výpise.“
To lze velmi spolehlivě automatizovat (viz Twig nebo Latte).

„Nejistotu máme i při ukládání jen surových dat, protože něco je potřeba escapovat při výpise a něco ne.“
Pokud automaticky escapuji všechno, tak hrozí akorát mylná neinterpretace některých HTML značek, což nepředstavuje bezpečnostní riziko a odhalí se výrazně rychleji, než zapomenuté escapování.

Str4wberry:
Chceš povedať, že DJPW má v DB dva stĺpce na surové a html data? tomu neverím. A neverím tomu preto, že to jednoducho zdvojnásobuje objem dát v DB. Nevidím žiadny dôvod pre také niečo. Pre editáciu príspevku stačí prehnať jeden príspevok cez nejakú funkciu "HtmlToBB" a máš pôvodné data.

Joker:
Existuje aj niečo ako pomer medzi vynaloženými prostriedkami a efektom, ktorý chcem dosiahnuť. Takže programovať supermaxiabstraktaplikáciu, ktorú sa v prípade konca sveta prevedie do PDF je zjavne neprimerané, ak je pravdepodobnosť, že do tej doby bude fungovať ako obyčajné internetové fórum viac ako 70%.
No a neviem či som to dobre pochopil, ale ako by si sa snažil vyvrátiť ideu "white listu" pri ukladaní dát. No z toho veru nemám moc dobrý pocit...(to je námet na novú knihu)

Jan Tvrdík:
Čo je to podľa teba "automaticky urobiť" niečo. Lebo mám pocit, že to isté sa dá napísať aj o ošetrení pri vstupe. A to či to program urobí alebo nie nemá s automatikou nič spoločné. To je o tom, či to do logiky výstupu naprogramuješ, alebo to zabudneš a teda je to riziko to isté ako pri vstupe.

Reakce na Jokera:
„Když se ukládá escapovaný obsah, tak to tak zdánlivě udělat můžu: Přidám si tam neescapované HTML a ono to nějak funguje. Do té doby než začnu dělat editaci nebo něco a dodatečně zjistím, jaká blbost to byla.“
Tak jinak. Pokud nejprve vložit HTML neumožňuji a chci tuto možnost zavést, stejně se přece nevyhnu tomu, aby to, co interpretované HTML být nemělo, bude zaentitováno, aby se odlišilo od interpretovaného HTML. Tedy v tomto bodě nevidím přínos čistého řešení.

„Když mám jen surová data (neescapuji nic), mám jistotu, že vždy musím řetězce na výstupu escapovat pro daný výstupní formát.“
Myslel jsem nejistotu v případě, že daný sloupec už je HTML, které chci interpretovat.

Ostatní otázky už závisí na typu konkrétní aplikace a pochopitelně někdy je lepší to, někdy ono.


Reakce na Jana Tvrdíka:
„což nepředstavuje bezpečnostní riziko“
To hledání „<adam>“ v „<adam>“ také ne. A stejně jako můžu zapomenout něco ošetřit — se mi i při automatickém ošetřování jej může podařit u některé položky mylně vypnout.


Reakce na Cama:
„Chceš povedať, že DJPW má v DB dva stĺpce na surové a html data?“
Právě nemá.

„Pre editáciu príspevku stačí prehnať jeden príspevok cez nejakú funkciu "HtmlToBB" a máš pôvodné data.“
No, je celkem otravné při zavádění nových značek vymýšlet i funkce pro zpětný převod. Krom toho je to komplikovanější pro provádění změn, kdy se při změně interpretace BB značek musí buď oželet zpětná kompatibilita, zanášet kód nějakou konstrukcí pro staré příspěvky, nebo odpovídajícím způsobem editovat HTML, aby odpovídalo novým úpravám BB značek.

Camo:
„Existuje aj niečo ako pomer medzi vynaloženými prostriedkami a efektom, ktorý chcem dosiahnuť.“
Ano. Právě tím argumentuji pro escapování na výstupu.
Implementace je u obou podobně pracná, ale escapování na výstupu má jednodušší údržbu.
Escapování na vstupu má složitější údržbu, ale v mnoha případech vychází výkonově lépe.
Kromě toho je escapování na vstupu podle mě náchylnější k chybám a, zatímco escapování na výstupu je použitelné univerzálně, escapování na vstupu je použitelné jen v určitých situacích.

„No a neviem či som to dobre pochopil, ale ako by si sa snažil vyvrátiť ideu "white listu" pri ukladaní dát.“
Narážka na ty validace?
Zkusím to blíž vysvětlit: Validace jsou samozřejmě potřeba, ale je zbytečné, aby sama aplikace měla dodatečná omezení.
Pokud se uživatel nesmí jmenovat O'Brian a jediný důvod je, že aplikace neumí uložit apostrof, tak je prostě lepší mít aplikaci, kde můžu povolit jakýkoliv znak, pokud chci.


Mimochodem, přijde mi zajímavé, že prohnat celý obsah $_POST přes mysqli_real_escape_string tu asi všichni považují za špatný nápad. Nebo alespoň nikdo neargumentuje, že je to dobrý nápad.
Ale prohnat celý obsah databáze htmlspecialchars, což je vlastně jiné provedení stejné myšlenky, hodně lidí jako dobrý nápad vnímá.

Tím to nechci srovnávat, rozhodně to druhé není zdaleka tak špatný nápad jako to první a ani netvrdím, že by se to nikdy nemělo dělat, ale nešel bych dál, než k tvrzení: „Obecně to není moc dobrý nápad, ale v konkrétních případech to může být užitečné.“

Vnímám to podobně, jako třeba pravidlo pro kódování aplikace: „Používat UTF-8, není-li pádný důvod použít něco jiného“.
Stejně tak tady: „Data se escapují funkcí odpovídající danému formátu a ve chvíli výstupu do daného formátu, není-li pádný důvod to udělat jinak“.

„Mimochodem, přijde mi zajímavé, že prohnat celý obsah $_POST přes mysqli_real_escape_string tu asi všichni považují za špatný nápad.“

Tak pokud člověk píše v čistém PHP, je nějaká obdoba magic quotes celkem nutnost pro neureal_escape_stringování se.

Str4wberry:
S tím rozhodně nesouhlasím. Jednak lze použít prepared statements a nebo si napsat na pár řádků funkci.

Jan Tvrdík:
Prepare statments majú nechutnú syntax(ale kôli jednému query písať a incudovať triedu na zapuzdrenie nechcem), robia o jednu požiadavku na DB viac a udržať v hlave myšlienku, že POST treba ošetriť mi príde ako samozrejmosť. Tým každý script začína, takže taká chyba je síce možná, ale dosť nepravdepodobná. Je to ako deklarácia premenných. Dobrý zvyk...

Joker:
"Mimochodem, přijde mi zajímavé, že prohnat celý obsah $_POST přes mysqli_real_escape_string tu asi všichni považují za špatný nápad. Nebo alespoň nikdo neargumentuje, že je to dobrý nápad."
Neviem čo tým presne myslíš, ale ošetriť dáta je nevyhnutnosť. Samozrejme pristupujem ku každej premennej osobitne, takže nie real_escape na celý post. A je podľa mňa dobrý nápad spojiť celé ošetrenie do vstupu, lebo inak budeš mať ošetrenie aj na vstupe aj na výstupe(dve miesta miesto jedného).

"tak je prostě lepší mít aplikaci, kde můžu povolit jakýkoliv znak, pokud chci."
Joker, Joker, ty budeš obhajovať neobhajiteľné aj keby čo bolo. Validáciu robíš preto, že to DB vyžaduje a white list zabezpečuje, že v budúcnosť sa ti do aplikácie nedostane znak, ktorý ti rozbije celú aplikáciu, prípadne zabezpečuje aplikáciu ak na niečo zabudneš(čo je nám ľuďom vlastné).

Camo:
„Prepare statments majú nechutnú syntax(ale kôli jednému query písať a incudovať triedu na zapuzdrenie nechcem)“
Čo je na nich nechutné? Keby sa podobnými názormi riadila väčšina programátorov, tak namiesto skutočne dobrých php frameworkov by sme mali nepodarky, ktorých jedinou úlohou by bolo vypísať Hello World vo viacerých farbách.
Ak používaš akýkoľvek lepší framework, tak má svoju databázovú vrstvu, ktorá do maximálnej možnej miery zjednodušuje pokladanie dotazov na databázu (z pohľadu programátora). A v takom prípade skutočne nevidím dôvod nepoužívať prepared statements.

„ošetrenie aj na vstupe aj na výstupe(dve miesta miesto jedného).“
To je ako s adidas - čím viac pásikov, tým viac adidas.

„Validáciu robíš preto, že to DB vyžaduje“
Som nevedel, že DB niečo vyžaduje. Ja som bol vždy v tom, že sa validácia robí preto, aby sa do polí vkladali iba tie dáta, ktoré tam chceme mať (napr. email, alebo číselné polia). A Jokerov prípad s nepodarenou validáciou (O'Brian) bol veľmi dobrý, sám sa s takými nezmyslami pomerne často stretávam.

shaggy:
Že o frameworkoch píšeš práve ty. Ešte pred nedávnom si na PC fore obhajoval funkcionálne programovanie v PHP. Ja som písal o tom, že kôli jednému query nebudem písať triedu. To či sa chem učiť pracovať s FW je tiež otázka. Jedna vec je že niečo zjednodušujú a druhá vec je, že vytvárajú v podstate nový jazyk. FW obsahú množstvo zbytočného kódu, ktorý ťahajú so sebou pri každej požiadavke. Ja mám na to jednu triedu, ktorá jedine inicializuje spojenie s DB. Každé query robím osobitne. Objekt vytvára samotné rozhranie mysqli. A PDO a pod.do toho neťahám zámerne najmä kôli tej rýchlosti.

Som nevedel, že DB niečo vyžaduje.
Ahá pardón, sa ti podarilo ma chytiť za slovíčko. Naozaj máš pravdu. Nevyžaduje to DB ale aplikácia. Ale išlo tam o ideu White listu a ten sa týka hlavne bezpečnosti pri spracovaní iným enginom...

"To je ako s adidas - čím viac pásikov, tým viac adidas."
Nenechaj sa oklamať. Štyri pásiky už nie sú Adidas.

Camo:
Ad prepared statements: To je samozřejmě nejlepší úroveň zabezpečení databázových dotazů.
Všechny ty šachy s escapováním atd. jsou řekl bych náhražka proto, že PHP+MySQL neumělo prepared statements. A teď už to je prostě ze setrvačnosti, protože se to všichni tak naučili.
Třeba v C# nebo Javě jsem neslyšel o funkci na escapování řetězce pro databázi. Když se po ní někdo shání, koukají na něj jak na exota a pak mu řeknou, ať používá parametrizované dotazy

„Samozrejme pristupujem ku každej premennej osobitne, takže nie real_escape na celý post.“
Ale celou databázi (resp. všechny řetězce v databázi) ošetřit na HTML je v pořádku?
Jestli ne všechny, tak jakou část? A co s tím zbytkem?

„A je podľa mňa dobrý nápad spojiť celé ošetrenie do vstupu, lebo inak budeš mať ošetrenie aj na vstupe aj na výstupe(dve miesta miesto jedného).“
Nebudu, to by byl nesmysl escapovat data dvakrát (by pak vyšel jiný výstup).
Nebo tím bylo myšlené, že se může najednou udělat ošetření pro databázi i pro HTML?
To je přece nesmysl, mám ošetřovat pro to, kam budu ukládat.
Když v tom databázovém sloupečku nebudou data, která se typicky vypisují do HTML, ale třeba se posílají zakódované v base64, měl bych už před uložením dat rovnou udělat base64_encode?
Když v tom databázovém sloupečku bude řetězec, který se typicky používá jako SQL dotaz, měl bych ho před uložením ještě jednou escapovat pro databázi, tj. mysqli_real_escape_string(mysqli_real_escape_string($data))?

„Validáciu robíš preto, že to DB vyžaduje“ - abychom neslovičkařili: „Nevyžaduje to DB ale aplikácia.“
A to je právě špatně.
Smysl validací je implementovat požadavky zadání. Když třeba zadání říká, že atribut PSČ má být české PSČ, má existovat validace, která to zajistí.
Kdyby třeba aplikaci platil člověk který nesnáší Iry a zadání znělo, že uživatel nesmí mít irské jméno, bude správné nepovolit jméno O'Brian.

Ale pokud se jménem O'Brian není žádný jiný problém, než že ho aplikace nedokáže uložit, je to zbytečné omezení té aplikace.
Samozřejmě často se omezením vyhnout nedá, ale přesně takhle by se to mělo vnímat: Jako omezení. Aplikace s takovým omezením je horší, než úplně stejná aplikace bez něj.

Připomenu situaci:
Escapuji data pro HTML už při ukládání do databáze. A co s uživatelským jménem? Dejme tomu, že si někdo chce zvolit O'Brian:
- Můžu apostrof ve jméně ignorovat. Fajn do chvíle, než v aplikaci bude Javascript typu: var userName = '<?php echo $userName ?>'; a někdo založí uživatele jménem '; location.href='malware';
- Můžu escapovat i jméno pro HTML. A řešit chyby typu že systémem vygenerované dopisy pro O'Briana začínají „Dear mr. O'Brian“
- Můžu neescapovat jméno pro HTML a zároveň tam nepovolit znaky, které bych jinak musel escapovat. O'Brian má prostě smůlu.
- Jak to podle mě dopadne obvykle: Jméno neřešit a teprve když to někdo zneužije dodělat escapování při výpisu. Výsledkem je těžko udržovatelná aplikace, kdy se některá data escapují na vstupu a jiná na výstupu a ten kdo to udržuje si prostě musí pamatovat, co kde.

Při escapování na výstupu jsou jen dva body:
- Nezapomenu escapovat na výstupu (což není těžké, protože všechno escapuji na výstupu)
- Zapomenu escapovat na výstupu a doplním to, když to někdo zneužije. To je ekvivalentní 4. bodu z předchozího, ale bez té složitější údržby.

Camo:
„Nenechaj sa oklamať. Štyri pásiky už nie sú Adidas.“
Presne tak - sám si si vyvrátil svoje tvrdenie. Skús prehnať vstup (reťazec), ktorý obsahuje aj html kód cez dvojnásobnú htmlspecialchars funkciu.
Alebo si zober, že máš administráciu - do databázy vkladáš html kód, na stránke ho potrebuješ zobrazovať ako klasické html, v administrácií ho potrebuješ vložiť do textarea.
Ak použiješ htmlspecialchars pri ukladaní, tak sa ti ten kód v textarea zobrazí. Horšie to už bude na stránke, namiesto funkčného html budeš mať escapovaný reťazec.

Joker:
Chyby pri escapovaní, ako je ten O´Brian sa netýkajú toho čo sa tu snažíme vyriešiť. Ide o to, či si vieš predstaviť túto diskusiu a stovky podobných stránok, ktoré by mali prekladať ten BB kód a robiť ešte kto vie čo všetko pri každej požiadavke. Lebo podľa mňa je rozdiel medzi aplikáciami v C a Jave kde máš väčšinou k dispozícii všetky hardwarove zdroje pre seba a aplikáciami PHP ktoré sú obmedzované počtom paralelných pripojení, hardwarom, šírkou pásma, prehliadačom, počtom požiadaviek a kto vie čím ešte. Ja si tiež viem predstaviť, že sa bude escapovať na výstupe, ale ide o to, či je to efektívne. Myslíš teda, že toto fórum tak môže fungovať?

shaggy:
Mám pocit, že moja administrácia tebou popisovaným problémom netrpí. Proste som to urobil tak ako treba. Takže na stránke mať escapovaný reťazec nebudem.
No a dvojité escapovanie by ťa malo napadnúť, keď budeš písať tú funkciu. Ak nie ,tak to zrejme uvidíš pri testovaní. Ale ak ani to nestačí, tak htmlspecialchars aj htmlentities majú od PHP5.2 štvrtý parameter, ktorý tomu zabráni.

Camo:
„Lebo podľa mňa je rozdiel medzi aplikáciami v C a Jave kde máš väčšinou k dispozícii všetky hardwarove zdroje pre seba a aplikáciami PHP ktoré sú obmedzované počtom paralelných pripojení, hardwarom, šírkou pásma, prehliadačom, počtom požiadaviek a kto vie čím ešte.“
Nepletieš jablká a hrušky? Ako súvisí šírka pásma, prehliadač s php? Napr. tieto dve hodnoty ovplyvňujú aj výkon aplikácie (stránky) napísanej v C# (asp.net).
Ale celkovo je to hlúpy argument - ak mám vlastný server, na ktorom mi beží web napísaný v php, tak tiež mám všetky hardvérové prostriedky iba pre seba. A naopak, ak máš asp.net web na zdielanom hostingu, tak máš prostriedky obmedzené rovnako, ako pri iných jazykoch. Joker poukazoval na úplne niečo iné, ty si to prekrútil a dosadil do absurdnej a nelogickej situácie.

„Mám pocit, že moja administrácia tebou popisovaným problémom netrpí. Proste som to urobil tak ako treba.“
Máš iba pocit? Ja napr. viem, že moje aplikácie s tým problém nemajú, lebo escapujem vtedy, keď treba. A ak by si sa držal tvojho dvojitého htmlspecialchars escapovania, určite by tvoja administrácia problém mala.

Camo:
„Chyby pri escapovaní, ako je ten O´Brian sa netýkajú toho čo sa tu snažíme vyriešiť.“
Ale týkají.
Moje otázka je: Chci-li ošetřovat HTML už na vstupu do databáze, tak kde všude (u kterých údajů)? To pak vede k těm čtyřem odrážkám, které všechny mají své problémy.

„či si vieš predstaviť túto diskusiu a stovky podobných stránok, ktoré by mali prekladať ten BB kód a robiť ešte kto vie čo všetko pri každej požiadavke“
V první řadě to s tím vůbec nesouvisí.
Kde se escapují data a jestli se výstup generuje při každém požadavku jsou úplně rozdílné věci.

Ve druhé řadě, i kdyby to znamenalo escapovat při každém požadavku, což opakuji není nutné, v drtivé většině případů by to nebyl problém vůbec žádný, htmlspecialchars() zdrojáku této stránky (do příspěvku 12 včetně, ~ 50,5 kB kódu) trvá asi 0,7 milisekundy (zkusil jsem dát 1000 cyklů do benchmarkovacího skriptu na webhostingu a párkrát spustit).

„máš väčšinou k dispozícii všetky hardwarove zdroje pre seba a aplikáciami PHP ktoré sú obmedzované počtom paralelných pripojení, hardwarom, šírkou pásma, prehliadačom, počtom požiadaviek a kto vie čím ešte“
Co je to za nesmysl?
Jakože kdybych totožnou funkčnost naprogramoval v PHP, C# (ASP.NET) a v Javě a všechno nahrál na stejný server (podporující všechny technologie), tak C# a Java budou mít k dispozici daleko víc hardwaru než PHP?

Souhlasim s tim, co bylo receno na zacatku. Ja to taky tak pouzivam.
db plain-text - zobrazovani htmlspecialchars
Vyjimecne se to koduje i do databaze, ale tehdy by mel clovek vedet nevyhody, ktere tu byli zmineny.
Souhlasim i s tim, jak je resene toto forum, jestli uklada do db html, v tomhle pripade je to vyhodnejsi nez bb a radeji nechat prechroustat editor bb na html a opacne nez se jen spolehnout na jeden druh prevodu. Vyhodou je, ze muzete vygenerovat obe varianty a porovnat s puvodnim kodem, zda se shoduji 1:1. Kdezoto u jednostranne konverze se musis spolehnout na to, e tam neni chyba a nemas to jak overit zpetne. Prijde mi, ze nema smysl tu probirat, jak diskuse funguje a proc. Kdo to programoval, tak urcite zvazil vsechny moznosti a vybral tu nejlepsi.

peta:
„Kdo to programoval, tak urcite zvazil vsechny moznosti a vybral tu nejlepsi.“
Jelikož jsem měl možnost si s kolegy aktivně se podílejícími na vývoji diskuse popovídat na téma, jaká zvěrstva a bezpečnostní díry ten kód původně obsahoval, dovolím si o tomhle pochybovat :-)

shaggy:
Naozaj mi to nedá: "server napísaný v PHP"????

No a ešte doplním pre všetkých čo nechápu čo som chcel povedať tým počtom pripojení, zdrojmi a pod. To sú všetko limitujúce faktory webových aplikácii. S escapovaním to naozaj priamo nesúvisí, ale fakt som nečakal, že nikto nepochopí, čo som tým chcel povedať...

Camo:
„Naozaj mi to nedá: "server napísaný v PHP"“
Myslím, že máš problém s čítaním, skús si prečítať ešte raz, čo som napísal:
„ak mám vlastný server, na ktorom mi beží web napísaný v php, tak tiež mám všetky hardvérové prostriedky iba pre seba“
Nikde som nepísal o serveri písanom v php.

„To sú všetko limitujúce faktory webových aplikácii“
Tak prečo si napísal toto?
„Lebo podľa mňa je rozdiel medzi aplikáciami v C a Jave kde máš väčšinou k dispozícii všetky hardwarove zdroje“
Uvedomuješ si, že webové aplikácie môžu byť písané v C# alebo Jave? Iba som poukazoval na nezmyselnosť tvojho tvrdenia.

shaggy:
Naozaj som to zle prečítal.

Tými aplikáciami v C a Jave som naozaj nemyslel na tie webové. Z toho čo som písal o zdrojoch a o tých faktoroch sa myslím dalo pochopiť, čo som chcel povedať.

Camo:
„No a ešte doplním pre všetkých čo nechápu čo som chcel povedať tým počtom pripojení, zdrojmi a pod. To sú všetko limitujúce faktory webových aplikácii. S escapovaním to naozaj priamo nesúvisí, ale fakt som nečakal, že nikto nepochopí, čo som tým chcel povedať...“
No protože to s webovými aplikacemi nesouvisí vůbec.
Web je vlastně jen komunikační kanál, třeba znám PHP skript, který sice jde spustit z prohlížeče, ale obvykle se spouští z konzole jako normální konzolová aplikace.
Na escapování to samozřejmě vůbec nic nemění.

Pokud argument byl, že php je určené hlavně pro web, tak to ASP.Net taky a přesto se tam escapování nepoužívá.

„aplikáciami v C a Jave“
Jedna poznámka, já a shaggy jsme zmiňovali C#, ne C, to je úplně jiný jazyk.

Joker:
Ja som sa len vyjadril, že syntax PHP prepare statments je hnusná a nepoužívam ju. Nerobte z toho podstatu témy. Neviem ako vyzerá syntax v C, C# alebo Jave a nieje to dôležité.
Tu ide stále o to, či je ošetrovanie dát na vstupe niečo nepredstaviteľného, resp, niečo pre čo by niekto z tunajších mohol niekoho nazývať hlupákom(však Joker). A stále to vychádza, že nie.. Imho aj vy sami ste sa vyjadrili, že to závisí od okolností(čo ani ja nepopieram).
No a vráťme sa ku argumentom:
Takže testy vraj ukazujú, že htmlspecialchars je tak rýchla, že to nestojí za úvahu. LENŽE háčik je v tom, že tu nejde o surovú htmlspecialchras, ale o komplex spracovania dát, ktorý vôbec nemusí byť tak triviálny, ako jedna natívna funkcia. Vrátim sa opäť k tomuto a stovkám ďalších fór. Viem, že implementujete určitú cenzúru, ktorá zrejme už nebude dávať také sexy výsledky v testoch ako htmlspecialchars. A o to ide. Že ak chceš ukladať surové dáta, tak musíš napr. v tomto prípade robiť preklad z BB do HTML a ešte aj tú cenzúru(a prezraďte, čo ešte???). Tieto testy ma zaujímajú nie tie predošlé.
A teraz vy. Už prosím nepíšte, že C nieje C#. To ja viem. Išlo o tie prepare statments, čo určite aj C nejak implementuje.

Camo:
„ide stále o to, či je ošetrovanie dát na vstupe niečo nepredstaviteľného“
To snad nikdo netvrdí. Debata začala ohledně toho, jestli (když neznáme bližší detaily projektu) někomu takový postup doporučit jako první možnost.

Jak jsem už psal, přijde mi to podobné, jako s kódováním.
Když se někdo zeptá, v jakém kódování má dělat stránky, odpověď je UTF-8.
Samozřejmě mít texty uložené třeba v kódování Kamenických, pokud pro to existuje důvod, není nějaká fatální chyba.
Ale když někdo přijde s dotazem v jakém kódování má dělat stránky a já (aniž bych věděl něco bližšího) doporučím kódování Kamenických, je to prostě špatná rada.[i][/i]

Právě proto nesouhlasím s výrokem: „Pokud muzes, je lepsi co nejvic operaci udelat uz pri ukladani“
Výhodnější totiž je to dělat přesně naopak: Nejsou-li pádné důvody pro zpracování dat už při ukládání, držet si uložená surová data.

„niekto z tunajších mohol niekoho nazývať hlupákom(však Joker)“
Nejsem si toho vědom, napsal jsem „je hloupost na oltář mantry ‚každá milisekunda dobrá‘ obětovat flexibilitu při práci s daty“, za čímž si pořád stojím.

„háčik je v tom, že tu nejde o surovú htmlspecialchras, ale o komplex spracovania dát“
Což přesně někoho, kdo tomu pořádně nerozumí, přivede do problémů.
Dobrým příkladem může být původní verze tohoto fóra, kde (jak jsem slyšel na srazu) se přesně ten přístup razil: Na zpracování dat před uložením do databáze byla jedna funkce, která dělala zrovna takové „komplexní zpracování“: Zpracovala HTML, BBCode, escapovala pro databázi, no prostě udělala všechno.
A tou funkcí se pak ošetřovala data.
Takže myslím jeden čas šlo docílit zajímavých efektů zadáním BBCode do uživatelského jména.

„Že ak chceš ukladať surové dáta, tak musíš napr. v tomto prípade robiť preklad z BB do HTML a ešte aj tú cenzúru(a prezraďte, čo ešte???)“
Tak ještě jednou: nemusím. Uložení surových dat nemá přímou souvislost s tím, že data zpracovávám při každém načtení stránky.

„ž prosím nepíšte, že C nieje C#. To ja viem. Išlo o tie prepare statments, čo určite aj C nejak implementuje.“
Ten protiargument ale byl, že „ve webovém prostředí“ je potřeba to dělat jinak než v C, což pro C# nedává smysl, protože C# se pro webové aplikace používá podobně běžně jako PHP.

Joker:
"je hloupost na oltář mantry ‚každá milisekunda dobrá"
No ja to vyjadrenie vnímam ako trochu ostrejšie než ty. Lebo Peta tam napísal, že "záleží na tom" a pretože sa bavíme o webe, tak to sedí. Čo som ja len podložil logikou tohoto fóra. Lebo tu nejde o žiadne milisekundy, ktoré dávajú testy fcie htmlspecialchars, ako som už uviedol.

"Tak ještě jednou: nemusím."
Ja tvrdím, že v tomto prípade musíš. Vysvetli mi prosím ťa čo tým myslíš, lebo mi to nedáva zmysel.