XSS ochrana OOP

apofis:
„Používám OOP“
Keby si nenapísal, tak ani nevieme (tento kód je strašný, či už ide o procedurálne alebo OOP programovanie).

„Myslíte, že je to dostatečně silná“
Nechcel si napísať dostatočne "šílená"? Ak hej, tak je.

Nerozumiem napríklad týmto úvodzovkám, načo sú dobré?
A čo ak zrazu budeš potrebovať ukladať html? Čo urobíš? Budeš to celé prepisovať a riskovať, že si rozbiješ aplikáciu?

Prečítaj si niečo o tom: http://phpfashion.com/escapovani-definitivni-prirucka a escapuj len vtedy, keď to treba a tak, ako je to v tej chvíli potrebné.

apofis:
Bohužel, z pohledu návrhu je ten kód úplně špatně.
• Takováto funkčnost rozhodně nepatří do konstruktoru
• Třída není zapouzdřená
• Je nesmysl všechny položky GET a POST prohánět přes strip_tags a htmlspecialchars, někdy to je nežádoucí
• Naopak je někdy potřeba použít jiné escapovací funkce
• Shrnutí předchozích dvou bodů: Escapovat je nutné podle toho, kam se ukládá, takže to takhle udělat nejde

shaggy:
„Nerozumiem napríklad týmto úvodzovkám, načo sú dobré?“
Jelikož se to tu objevuje dnes a denně, přidal jsem to do FAQ.

apofis:
„Nevím co je na ní šíleného.“
jestli myslis, ze nic a neveris zdejsim diskutujicim, proc jsi sem daval ten kus kodu hodnotit?

pokud postova data pouze vypisujes na strance, pak je htmlspecialchars spravnou variantou osetreni. Pokud je ukladas do DB, coz u formularu predpokladam, htmlspecialchars spravnou cestou neni, osetruj s mysql_real_escape_string - tim se dostavame k tomu, co shaggy myslel tim odkazem, ktery uvedl.

„Pokud bych to někdy potřeboval není problém z toho pomocí např. in_array vyřadit jakýkoliv post.“
nejde to proti logice aplikace? Mit neco napsaneho a v zavislosti na zbytkovem kodu pak jiz stavajici funkci veci ohybat, aby to nejak fungovalo? Nemyslim, ze to je spravna cesta.


Omlouvam se za tykani, na zdejsim diskusnim foru je to sila zvyku. S nikym ze zdejsich diskuteru jsem take ovce nepasl :)

apofis:
OOP jsem tam napsal z důvodu kontextu constructu. nevidím důvod proč bych to tam nemohl mít napsáno.
To by mě zajímalo, jaké by bylo praktické užití této třídy. Vždyť když napíšeš tohle do konstruktoru, tak při každé nové instanci se spustí ošetření? Není tak trochu zbytečné tvořit instance X tříd, které obsahují jenom nějaký konstruktor?

Navíc ošetřuješ, jak již bylo uvedené výše špatné - dotazy do databáze, které obsahují vstup od uživatele je třeba ošetřit mysql_real_escape_string (pozor také na direktivu magic_quotes_gpc) a výstup na stránku (při výpisu) htmlspecialchars.

Osobně bych na ošetření vytvořil dvě metody na ošetření vstupu a výstupu a umístil je do nějaké vhodné třídy, rozhodně ne do konstruktoru.

[#3] apofis:
Objektově-orientované programování je postavené na zásadách, které jsou neslučitelné se způsobem uvažování použitém v uvedeném příspěvku.

„OOP jsem tam napsal z důvodu kontextu constructu. nevidím důvod proč bych to tam nemohl mít napsáno.“
V konstruktoru třídy má být nějaké úvodní nastavení nebo načtení té třídy. Rozhodně tam nemá být žádná výkonná funkčnost a zejména ne funkčnost, která ovlivní i okolí třídy.
Ona by třída vzhledem k principu zapouzdření své okolí neměla ovlivňovat nikdy, ale v PHP by to za určitých okolností s přimhouřením oka šlo tolerovat. Ovšem aby třída měnila své okolí v konstruktoru, tj. ve skriptu udělám $neco = new Trida(); a změní se mi GET a POST, to je opravdu šílenost.

„Aplikace co píšu nepotřebují ukládat HTML kód jsou to sady jednoduchých vstupních formulářů. Pokud bych to někdy potřeboval není problém z toho pomocí např. in_array vyřadit jakýkoliv post.“
Tohle je další základní chyba.
Mezi základy OOP patří znovupoužitelnost tříd a také Open-closed principle: Třída má být otevřená rozšiřování, ale uzavřená úpravám.
Smyslem objektového návrhu je to, aby když budete v jiné aplikaci řešit stejný/podobný problém, mohl jste využít stejnou třídu, nebo si vytvořit odvozenou třídu s rozšířenou funkčností.
Přitom ale třídy mají být navržené s myšlenkou, že po jejich dokončení a otestování, že v dané aplikaci plní svou funkčnost, se do jejich kódu už nikdy nebude zasahovat (uzavřené pro úpravy). Návrh zároveň vychází vstříc možnostem rozšíření funkčnosti třídy hlavně pomocí dědění (je otevřený pro rozšíření).

Čili myšlenka „Udělám třídu s natvrdo zadrátovanou velmi specifickou funkčností a když to jinde budu chtít jinak, třídu duplikuji a pozměním“ je z pohledu OOP fundamentálně špatná.