ugrás a tartalomhoz

magic_quotes_gpc sql injection ellen nem elég?

Anonymous · 2005. Aug. 15. (H), 15.12
Egy másik fórum témában már felvetettem a kérdést, itt akkor folytatnam:
Egy "select * from users where name='$_POST[name]' and pass='$_POST[pass]'" milyen veszélyt rejt "magic_quotes_gpc = 1" mellett?

php.net:
" A mysql_real_escape_string() a MySQL könyvtár mysql_real_escape_string függvényét hívja meg, amely visszaperjeleket illeszt a következõ karakterek elé: \x00, \n, \r, \, ', " és \x1a."

"\x00, \n, \r, \, \x1a" ezeket miért kell levédeni?

üdv.: Zsolt
 
1

Kiegészítő kérdés

fberci · 2005. Aug. 15. (H), 16.24
Ezzel kapcsolatban azt szeretném megkérdezni még, hogy ha a magic_quotes 1-en van, akkor a mysql_real_escape_string() nem illeszt-e be túl sok visszaperjelet?

Üdv.: fberci
2

<Nincs cím>

Anonymous · 2005. Aug. 15. (H), 16.30
De sokat illeszt be, ezért így kell:

if (get_magic_quotes_gpc())
       $ertek = stripslashes($ertek);
$ertek = mysql_real_escape_string($ertek);
üdv.: Zsolt
3

adatbázis függőség és PHP sebezhetőségek

Hojtsy Gábor · 2005. Aug. 15. (H), 19.55
Nos, először is nem minden adatbázisban a visszaperjel a kivételes karakterek jelzője. Van ahol az aposztrófokat meg kell kettőzni például, és az a kivételes aposztróf jelzés egy karaktersorozatban. Ezért nem célszerű egy konkrét adatbázis megvalósításhoz kötni a PHP-t, és ezért nem javasolják a magic_quotes_gpc bekapcsolását.

Ezen felül még az a probléma is fennáll, hogy nem minden adatot adatbázisba akarsz betenni, hanem mondjuk egy hibásan kitöltött űrlapnál vissza akarod juttatni a felhasználónak. Akkor a plusz visszaperjelek határozottan zavaróak, és stripslashes()-t kell alkalmazni. De ha adatbázisból töltöd fel ugyanazt az űrlapot, akkor viszont nem kell, és így növeled az alkalmazásod bonyolultságát feleslegesen, sosem tudod, most milyen adattal dolgozol... Rasmus Lerdorf, a PHP elindítója javasolta ennek a lehetőségnek a teljes törlését a PHP 6-ból! Szóval nem célszerű használni!

A \ természetesen kivételesnek számít, mert azt használja a MySQL a kivételes karakterek jelzésére, az aposztróf és idézőjel a karaktersorozat beágyazás miatt fontos, a \x00 pedig a nulla bájt, ami PHP-ben a karaktersorozatok végét is jelzi, és ezt is érdekes támadásokra lehet felhasználni. A többi dolgot a bináris adatok miatt jelzi kivételesnek, és ráadásul figyelembe veszi az aktuális (paraméterben megadott) kapcsolat által használt karakterkódolást is, úgyhogy csupa jót tesz veled.
4

thx

Anonymous · 2005. Aug. 15. (H), 23.04
Köszönöm az új információkat. Kezdő php programozok számára szerintem biztonságosabb a default magic_quotes_gpc on. Elég ha csak magamból indulok ki, kb 1 hónap php-zés után hallottam először az sql injection-ről.

üdv.: Zsolt
5

az már jó :)

Hojtsy Gábor · 2005. Aug. 16. (K), 00.01
Egy hónap az már jó, van aki évekig nem hallott, persze én sem így születtem :). A magic_quotes nem elég, mert nem tudhatod, hogy honann jön az adat. Ha egy függvénybe teszed mondjuk az SQL parancsot, akkor azt lehet, hogy olyan adattal fogod majd meghívni amit fájlból, adatbázisból, stb. veszel elő, így megkerülhető lesz a dolog, és sebezhető lesz a program.
6

Egyéb támadási módok

Hodicska Gergely · 2005. Aug. 16. (K), 10.31
Szia!


Ez esetleg érdekelhet: PHP a frontvonalon, védekezés a bemeneten.


Felhő
7

mysql_escape_string() nem megy

fberci · 2005. Aug. 20. (Szo), 17.52
Meggyőztetek, és megpróbáltam kikapcsolni a magic_quotes_gpc-t. Ez sikerült is (minden fájlban ini_set()-tel). Ezután pedig minden sql kérést mysql_escape_string()-eztem (azért nem real_escape-pel, mert 4.1.2-es a php). Ekkor a következő hibát adta ki a mysql_error():

You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '\'1124552416\', \'195.56.240.107\', \'amazonas-2139.adsl.datane

Mi lehet a baj?

Üdv.: fberci
8

Rájöttem...

fberci · 2005. Aug. 20. (Szo), 18.22
Közben rájöttem a megoldásra, hogy nem az egész kérést kell átadni a mysql_escape_string()-nek.

Üdv.: fberci