Dotaz: PHP, MySQL a SQL injection

[Petr Rapouch]

Dobry den,

po byvalem kolegovi nam zustal takovy PHP moloch pro evidenci skladu, dodavatelu, odberatelu, faktur, ... Predesilam, ze PHP rozumim jako koza petrzeli. Dostal jsem nicmene za ukol doplnit tam moznost, aby odberatele mohli videt faktury, ktere jsme jim vystavili.

Nejak jsem to uplacal, funguje to, akorat bych rad mel jistotu, ze to nepujde "haknout", nez tam pustim nekoho zvenci.

Vim, uplne vas slysim, co vsechno mi ted chcete napsat. Aby se z toho nestal gulas, pokusim se vase rady trochu usmernit.

V prve rade neni v tom zadny JavaScript. Dale pobezi to na renomovanem webhostingu (nebudu jmenovat, musite mi verit). Dalsi ujisteni shrnu do zkratky: atd...

Verim, ze byste mi radi pomohli i do schodu :) ale ted mi jde fakt vyhradne o to, aby tam nebylo mozne provest SQL injection.

Pouziva to MySQL rozsireni, ktere je "deprecated". Vim, bohuzel je to takovy moloch, ze neni v mych silach to prepsat na MySQLi nebo PDO, ani tam nasadit "prepared statements".

V index.php, hned za prihlasenim do databaze jsem objevil toto:

array_walk_recursive($_GET,  function(&$v, $k) {$v = mysql_real_escape_string(trim($v));});
array_walk_recursive($_POST, function(&$v, $k) {$v = mysql_real_escape_string(trim($v));});

Jestli to chapu dobre, tak to veskere predane parametry prozene pres funkci trim() a mysql_real_escape_string().

Tedy ptam se: staci to takhle? A k cemu je tam prosimvas ta promenna $k, ktera se tam nikde dal nepouzije?

Dekuji

Odpovědi

[Sten]

Pravděpodobně to stačí, ale záleží na tom, jak se s těmi řetězci dále pracuje.

$k je klíč v tom poli, které se prochází.

[Petr Rapouch]

Dekuji!

Jen jeste prosim o upresneni "co" napriklad, by se s temi retezci mohlo dit, aby vznikl problem?

Prip. jestli je moznost "to neco" vygrepovat ze zdrojaku, abych se mohl presvedcit, ze se to tam nedeje?

Ted jsem treba zkousel grepovat, jestli se promenne nepouzivaji v nazvech souboru, ktere se natahuji za behu. A podle vseho nepouzivaji.

Dekuji za Vas cas

[Jendа]

Funkční problém vznikne, když řetězec neuložíš do databáze, ale hned vypíšeš klientovi - bude escapovaný. Postupně se takhle třeba při každém editu budou exponenciálně nabalovat backslashe,

Jen jeste prosim o upresneni "co" napriklad, by se s temi retezci mohlo dit, aby vznikl problem?

Třeba když se bude dekódovat z urlencode/base64, takže tam můžou vzniknout znaky, které původní escape neviděl. Nebo když se budou dělat nějaké substituce regexpem, takže třeba hacker dokáže aplikaci přinutit, aby smazala backslashe.

[Sten]

Např. pokud ten řetězec uložíte do databáze, příště ho načtete a znovu použijete v SQL. Nebo pokud ho odescapujete, abyste ho mohl zobrazit, a použijete v SQL.

[Kit]

Tohle je dobrá ukázka.

[Kit]

Správně to není, protože vstupy mají zůstat immutable. Databázi by to však ochránit mělo.

Funkce mysql_real_escape_string() by se měla použít až těsně před slepením SQL dotazu. Používá se totiž jen pro stringy - na čísla je nutné použít jiný typ ošetření vstupu.

[Josef Kufner]

Jak už bylo řečeno, budou se ti množit lomítka a nemusí to vždy zafungovat.

Projdi celou aplikaci a uprav to na používání PDO s placeholdery. Měla by to být relativně snadná uprava, pokud si pečlivě připravíš funkci, která bude dobře sedět do stávajícího kódu. Pak můžeš tyto dva ošklivé řádky smazat a aplikace bude bezpečná a funkční.

[Filip Jirsák]

Proti jednoduchému SQL injection by to chránit mělo, jak píšou ostatní. Ovšem je to založené na předpokladu, že mysql_real_escape_string parsuje SQL absolutně stejně, jako parser dotazů v MySQL. Takže pořád existuje nepatrná možnost, že budete mít třeba jinak nakonfigurované PHP a jinak MySQL (třeba znakovou sadu), nebo bude nepatrná odchylka v parseru, a útočník dokáže tuto „ochranu“ pokořit. Nebyl by to klasický útok pomocí ';, ale něco sofistikovanějšího.

[Josef Kufner]

Jinak přesně tohle kdysi dělaly magic quotes, ale to už naštěstí bylo z PHP odstraněno. Tak se můžeš podívat, proč je nepoužívat – je to i odpověď na tvou otázku.