Autor Zpráva
apofis
Profil
Zdravím,
chtěl bych znát váš názor na ochranu před XSS.
Používám OOP a vždy volám jednu hlavní třídu, která má při svém vytvoření zařídit ochranu.
(Výhoda, že na to nemusím pak dál už myslet).
Třída se vytváří vždy při každém obnovení stránky.

function __construct()
    {
        foreach (array_keys($_POST) AS $posts)
        {
                
            $_POST[$posts]=strip_tags("$_POST[$posts]");
            $_POST[$posts]=htmlspecialchars("$_POST[$posts]",ENT_QUOTES);
                
        }
        
        foreach (array_keys($_GET) AS $gets)
        {
        
            $_GET[$gets]=strip_tags("$_GET[$gets]");
            $_GET[$gets]=htmlspecialchars("$_GET[$gets]",ENT_QUOTES);
        
        }
        
    }

Myslíte, že je to dostatečně silná ochrana???
Díky
Mira
shaggy
Profil
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é?
strip_tags("$_POST[$posts]");
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
Profil
OOP jsem tam napsal z důvodu kontextu constructu. nevidím důvod proč bych to tam nemohl mít napsáno.
Souhlas úvozovky jsou zbytečné je to prostě síla zvyku.
Nevím co je na ní šíleného. 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.
A jelikož posty používám jen na formulářová data přišlo mi dobré když to vždy projede vše.

Jinak tam mám ještě jednu (určitě zbytečnou funkčnost) na průchod polem pokud by přišlo v $_POST

(is_array($_POST[$posts]))
            {
                foreach ($_POST[$posts] AS $index=>$value)
                {
                    $_POST[$post][$index]=strip_tags($_POST[$posts][$index]);
                    $_POST[$post][$index]=strip_tags($_POST[$posts][$index],ENT_QUOTES);
                }
                
                
            }

Nic šíleného na ní nevidím. Pokud máte lepší řešení jsem s ním rád se naučím nové věci.
PS: netykáme si, ovce jsme ve vysokých tatrách spolu nepásli
Joker
Profil
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.
panther
Profil
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 :)
Again
Profil
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.
apofis
Profil
Nejdřív všem děkuji za rady a názory, určitě se nad tím dál zamyslím.

„Nevím co je na ní šíleného.“ - Kdy tam byl napáno "je to šílenost a nebezpečné mít v constructu..." via Joker tak ani nepínu, napsat "Je to šílené" a dost je trochu matoucí.

mysql_real_escape_string je pro mě trochu nepoužitelný jelikož komunikuju s DB pomocí PDO a používám PREPARE a BIND (a většinou nepoužívám MySQL :-)).
Funkci tam mám protože jsem od progamátorské přírody líný a nebavilo mě pořád testovat 1000+1 textbox :-).
Ale s tím zapouzdřením jste mě docela nahlodal asi to trochu upravím a budu pouštět jen na vždy konkrétní formulář.
Děkuji
Joker
Profil
[#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á.
apofis
Profil
Joker:
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.
Děkuji za vysvětlení, změním kontrukci a použití funkce aby odpovídala standardům.
Díky

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: