Autor | Zpráva | ||
---|---|---|---|
JirkaP Profil * |
#1 · Zasláno: 11. 2. 2012, 22:02:16
Zdravím,
zřejmě hloupý dotaz, ale nenašel jsem zatím odpověď. Přečetl jsem X článků o escapování (vč. definitivní příručky na phpfashion), ale nejsem moudřejší. Píšu script, který vyhodnotí referer (pokud je poslán) a v případě, že referer pochází třeba z Googlu, pokusí se z něj získat hledanou frázi. Ptám se, je nutné $_SERVER['HTTP_REFERER'] nějak ošetřit dříve než budu získanou (vrácenou) hodnotu vypisovat do stránky, nebo ukládat do databáze? Myslím pro zpracování uvnitř scriptu - tedy na vstupu. Pokud ano, jak?
Obecně: Hrozí nějaké riziko pokud $_GET, $_POST, $_SERVER, ... použiju uvnitř skriptu tak jak jsou, nebo je třeba použít něco jako $osetrena_promenna = osetrovaci_funkce($_GET); a pracovat s $osetrenou_promennou. V případě, že ano, jak data ošetřit když nevím co dostanu? Zkoušel jsem rawurlencode() a rawurldecode(), někde jsem použil preg_match, ale při zpracování ve skriptu někdy to použít nelze - potřebuji původní data. Je mi jasné, že při výpisu do stránky je třeba použít htmlspecialchars, při zápisu do databáze mysql_real_escape_string atd. Příklad: Hrozí nějaké riziko viz komentář ve skriptu níže. (odsud / potud) $parsePhpUrlQuery = parse_url($_SERVER['HTTP_REFERER'], PHP_URL_QUERY); // odsud if(isset($parsePhpUrlQuery)){ parse_str($parsePhpUrlQuery, $urlQueryArray); if(isset($urlQueryArray['q'])){ return $urlQueryArray['q']; // potud } } |
||
Str4wberry Profil |
#2 · Zasláno: 11. 2. 2012, 22:14:16
Vždyť sis odpověděl sám. „Je mi jasné, že při výpisu do stránky je třeba použít htmlspecialchars, při zápisu do databáze mysql_real_escape_string atd.“
|
||
JirkaP Profil * |
#3 · Zasláno: 11. 2. 2012, 22:48:05
Špatně jsem se zeptal. Pardon. Výstup je jasný. Jde mi o ošetření na vstupu - tedy do okamžiku než to chci někam vypisovat nebo ukládat. Jde mi o to, zda hrozí, že někdo pošle třeba přes $_post, nebo $_server nějaký zlý kód, který se vykoná ještě než se to dostane k echo, nebo return.
BTW: Sám neposílám referer a házelo mi to tu hlášku, že "Tato kombinace jména a hesla je neplatná" a nelze vytvořit téma. |
||
Alphard Profil |
#4 · Zasláno: 11. 2. 2012, 22:53:29
JirkaP:
Ne, nemůže. PHP má na vstupu stringy a dále s nimi pracuje jako se stringy, tj. nevykoná je. Předpokládám, že nedostanete tak blbý nápad, že byste někde použil eval(). Do jiných kontextů se escapuje z toho důvodu, že se ztrácí informace o tom, co je hodnota proměnné a co ne. Např SQL dotaz, databáze ho dostane jako řetězec, kde jsou hodnoty v apostrofech. Kdyby vaše proměnná obsahovala apostrof, z pohledu SQL server by byl považován za ukončení řetězce a došlo by buď k syntaktické chybě, nebo cílenému útoku. Proto escapování, escapovaný apostrof není považován za apostrof ukončující řetězec. |
||
JirkaP Profil * |
#5 · Zasláno: 11. 2. 2012, 23:10:37
Aha, děkuji za vysvětlení.
Učím se a napadlo mě (měl jsem obavy) zda by si někdo nemohl třeba upravit browser a např. v $_SERVER['HTTP_USER_AGENT'] nemohl poslat nějaký škodlivý kód. Byla to očividně chybná úvaha laika.
Přesto se ujistím, že uvažuji správně: Je tedy správné (nikoliv zbytečné) na vstupu např. $_GET kontrolovat přijímaná data - tedy když očekávám číslo měl bych zkontrolovat, že dostávám číslo nebo když očekávám, že v přijímaných datech nebude třeba otazník, tak že tam skutečně není. |
||
Alphard Profil |
#6 · Zasláno: 11. 2. 2012, 23:37:24
JirkaP:
Podle situace, kontrola může skončit negativně a vzniká chybový stav, který se musí nějak ošetřit, to je práce navíc :-) Takže když to jde, nechám program proběhnout co nejdál standardní cestou a pak se to nějak vyřeší. Např. vypisuji článek a v adrese očekávám jeho id. Neřeším, co skutečně dostanu, ale databázová vrstva to explicitně přetypuje na číslo, pokud tam bylo něco podvržené, bude tam 0. Pokud se článek nenajde ( where id = 0 ), hodí se 404 nebo něco...
Když budu registrovaž uživatele a ve jméně není povolený otazník, tak prostě musím zkontrolovat příchozí řetězec a informovat uživatele o chybě, tam to jinak nejde. |
||
JirkaP Profil * |
#7 · Zasláno: 12. 2. 2012, 00:08:17
Super. Děkuji.
|
||
Časová prodleva: 12 let
|
0