Miért nem kerülhetjük el az összes felhasználói bevitelt a „varázslat” használatával?

A varázslat alkalmazásakor nem tudni, hova kerülnek az adatok. A mágikus idézetek tehát olyan adatokat rombolnak, amelyek hacsak nem szabadon íródnak az adatbázisba.

Csak az ügyfélnek visszaküldött HTML válaszban használhatók fel. Gondoljon egy olyan űrlapra, amelyet nem töltöttek be teljesen, és ezért újra megmutatja a felhasználónak. Varázslatos idézetekkel az első próbálkozáskor bevitt adatok mostantól SQL-nek kerülnek, ami értelmetlen egy HTML-oldalon. Még ennél is rosszabb: a második beküldéskor az adatok ismét megkerülésre kerülnek az SQL-ből.

Miért nem voltak "elég jó" az összeadások?

Problémái vannak a többbájtosakkal karakterek:

  '27 \ 5c 뼧 bf 5c  

Ez két bájt, de csak egy Unicode karakter.

Mivel addlashes nem tud semmit az Unicode-ról, a bf 27 bemenetet bf 5c 27 -né alakítja. Ha ezt egy Unicode-tudatos program olvassa, akkor as '-nek tekintjük. Boom.

Erre a kérdésre jó magyarázat található a http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string oldalon.

Mi a baj a DB-specifikus escape funkciók használatával, és miért volt jobb, mint az összecsapások?

Jobbak, mert biztosítják, hogy a szökő értelmezze a adatokat ugyanúgy, ahogy az adatbázis teszi (lásd az utolsó kérdést).

Biztonsági szempontból rendben vannak, ha minden egyes adatbevitelhez használja őket. De fennáll annak a veszélye, hogy bármelyiket elfelejtheti valahol.

Szerkesztés : Ahogy a getahobby hozzáadta: Vagy használhatja az xxx_escape_strings számokat anélkül, hogy idézőjeleket adna hozzá az SQL-be utasítás és anélkül, hogy megbizonyosodna arról, hogy tényleges számok-e, a bemenet öntésével vagy konvertálásával a megfelelő adattípusra /Szerkesztés

Szoftverfejlesztési szempontból azért rosszak, mert sokkal nehezebbé teszik az egyéb SQL adatbázis-kiszolgáló szoftverek támogatásának hozzáadását.

Miért üdvözlik a kész keretrendszerekkel és az OEM-kel ellátott utasításokat arany standard az SQL? Miért jobbak?

Az OEM a szoftvertervezési okok miatt többnyire jó dolog. Sokkal könnyebb támogatni más adatbázis-kiszolgáló szoftvereket. Van egy objektumorientált felülete, amely sok kis adatbázisspecifikus összeférhetetlenséget kivonat.

Miért nem tudok SQL-injekciót végrehajtani ezekkel az [előkészített utasításokkal], ahol, mint ahogy az előzőekben is megtehetném az említettek jelentése?

Itt fontos az elkészített utasítások " állandó lekérdezés változó paraméterekkel " része. Az adatbázis-illesztőprogram automatikusan megkerüli az összes paramétert, anélkül, hogy a fejlesztőnek gondolkodnia kellene rajta.

A paraméterezett lekérdezések szintaktikai okokból gyakran könnyebben olvashatók, mint a normál lekérdezések, amelyek elkerültek. A környezettől függően előfordulhat, hogy valamivel gyorsabbak.

A statikus kódelemző eszközök segítségével mindig ellenőrizhető az előkészített utasítások használata paraméterekkel. Az xxx_escape_string hiányzó hívását nem észleljük olyan könnyen és megbízhatóan.

Nem sikerül-e egy programozónak valahogy mégis ezt elcsavarni? Mire kell figyelniük?

Az "elkészített állítások" azt jelentik, hogy az állandó . Az előkészített utasítások dinamikusan generálásával - különösen a felhasználói bevitel segítségével - továbbra is fennáll az összes injekciózási probléma.

[1.] Miért nem kerülhetjük el az összes felhasználói bevitelt a "varázslat" használatával?

Mivel a bűvös idézetek két szempontból megszakadnak:

1. Nem minden $ _ (REQUEST / GET / POST) adat kerül a DB-be. És hogy bármilyen értelme legyen, el kell menekülnie a beviteltől.
2. Ők a addlasheshes megfelelői (lásd a [2.] -hoz fűzött megjegyzésemet), ezért valójában nem biztonságosak.

[2.] Miért nem voltak "elég jóak" az összeadók?

Sokan vannak a addlashes korlátozásból való kilépés módjai, ezért alapvetően hibás, de megpróbálja használni.

[3.] Mi a baj a DB-specifikus escape használatával funkciók, és miért volt jobb, mint az összecsapások?

Semmi sem igazán. Egyszerűen ez a mantra arról, hogy az OEM / előkészített termékek miért "jobbak". sokkal jobbak, mint a addlashes , mivel számos tényezőt figyelembe vesznek, beleértve a kódolást is. Itt van egy kis titok; A PDO ezeket belsőleg használja, de nem a addslashes...

[4.] Miért üdvözlik a kész keretekkel és az OEM-kel ellátott állításokat arany standardként az SQL? Miért jobbak? Miért nem tudok ezekkel SQL-injekciót végrehajtani, ahol, ahogy az előbb említett eszközökkel TETTEM?

Ők nem az arany szabvány , nem "biztonságosabb" , mint a DB-specifikus funkciók, és ezekkel is megteheti az SQL injekciót . És nem, az SQL injekciót nem végezheti el megfelelően fertőtlenített bemenettel.

Mint minden ottani technológia esetében, a fejlesztők is vallási (fanatikus?) Tendenciákat fejlesztenek ki minden „új” iránt. Ezért kapsz tapasztalt Zend Minősített Mérnököket (TM), akik nem ajánlják az előkészített állításokra való áttérést.

A valóság azonban az, hogy minden azon múlik, hogy tudod, mit csinálsz. Ha egy cikket numerikus azonosítójával tölt be, akkor nincs szüksége semmiféle menekülésre, még kevésbé az OEM-re. Egyszerűen meg kell győződnie arról, hogy az azonosító valóban egész szám.

Reálisabb szempontból az általános szabály nem az OEM vagy az elkészített utasítások használata, hanem a megfelelő függvények használata, vagyis: kell használnia a mysql_real_escape_string () -t a addlashes () vagy mysql_escape_string().

helyett

[5.] Egy programozónak nem sikerül valahogy mégis ezt elcsesznie? Mire kell figyelniük?

Természetesen! De nem "mire kell figyelni", hanem "tudja, mit csinál".

Látja, eval ($ _ GET ['code']) * teljesen megfelelő, ha megfelelő helyen használják (például egy helyi PHP Test Runner programban).

Ha egy feltételes lekérdezés futtatásához ORM-et használ, akkor közvetlenül kódot ad meg, ezért előfordulhat, hogy az SQL injekció megszerzésének esélye, ha nem jól csinálod (a kérdéses ORM-től függ). (Hipotetikus) Példa:

  // update () egy // // feltételnek megfelelő oszlop értékét állítja be. - a szökés itt automatikus // | .-- hipotetikus SQL injekció // v vDb () - >update ('név', $ _ GET ['új név']) - >where ('id ='. $ _ GET ['id']);  

(* Csak azt tudom elképzelni, hogy a számtalan szakember e ezen veri a fejét)

A nap végén meg kell szüntetni a bevitelt, hogy megvédje az SQL Injection formájú lekérdezéseit. Az olyan paraméterezett lekérdezési könyvtárak, mint a PDO és az ADODB, menekülést használnak , csupán annyit tesznek, hogy ezt a gyakorlatot hallgatólagosan biztonságos módon érvényesítik. Azáltal, hogy a magic_quotes_gpc nem NEM , ez alapvetően hibás megközelítés a problémához.

1) A menekülés problémás lehet, ha nem érted, mit csinálsz. Ez a típusú probléma továbbra is kihasználható, ha a magic_quotes_gpc engedélyezve van. pre>

PoC Exploit: http: //localhost/vuln.php? id = sleep (30)

javítás:

  mysql_query ("válasszon * azoktól a felhasználóktól, ahol id = '". összecsap (($ _ GET [id]). "" ");  

Lecke: Az sql injekció kihasználásához nincs szükség idézőjelekre.

2) Mondjuk, hogy csak az idézőjelektől menekül:

  mysql_query ("válasszon * azon felhasználók közül, ahol name = '". htmlspecialchars ($ _ GET [név], ENT_QUOTES). "' és id = '". htmlspecialchars ($ _ GET [id], ENT_QUOTES). "" "); kód> 

PoC Exploit: http: //localhost/vuln.php? name = \ &id = + vagy + sleep (30) / *

Javítás :

  mysql_query ("válasszon * azoktól a felhasználóktól, ahol a name = '". összecsap (($ _ GET [név]). "" és id =' ". ($ _GET [id]). "" ");  

Lecke : A visszavágások ugyanolyan veszélyesek idézőjelként.

3) Mi a helyzet a nyelv kódolásával?

  mysql_query ("SET CHARACTER SET 'gbk'"); mysql_query ("select * from user from where name = '". addlasheshes ($ _ GET [név]). "" "); / code> 

PoC Exploit: http: //localhost/vuln.php? name =% bf% 27 = sleep (30) / *

Javítás: erős>

  mysql_query ("SET CHARACTER SET 'gbk'"); mysql_query ("select * from user where name = '". mysql_real_escape_string ($ _ GET [name]). "" ") ;  

Következtetés:

Szükség van a szökésre, hogy megakadályozzuk az sql injekciót egy alkalmazásban. A PHP-ben a PDO és az ADOB nagyszerű paraméterezett lekérdezési könyvtárak, amelyek kikényszerítik a felhasználói bemenetek elkerülését. A probléma az, hogy sok programozó nem érti, mi a menekülés. A védekezés legjobb módja annak a könyvtárnak a biztosítása, amely betartja ezt a biztonságpolitikát, mert nem kell megértenie a menekülési szabályokat.

A DB-specifikus menekülési funkciókról. Sokféle forgatókönyv fordulhat elő az SQL injekcióban, annak ellenére, hogy a mysql_real_escape_string () -t használták. A LIMIT és az ORDER BY valóban trükkös!

Ezek a példák kiszolgáltatottak az SQL injekcióval szemben:

  $ offset = isset ($ _ GET ['o'])? $ _GET ['o']: 0; $ offset = mysql_real_escape_string ($ offset); $ sql = "SELECT userid, felhasználónév FROM sql_injection_test LIMIT $ offset, 10";  

vagy

  $ order = isset ($ _ GET ['o'])? $ _GET ['o']: 'userid'; $ order = mysql_real_escape_string ($ order); $ sql = "SELECT userid, felhasználónév FROM sql_injection_test ORDER BY" $ order "";  

Mindkét esetben nem használhatja a 'felhasználást a beágyazás védelmére.

forrás: A váratlan SQL-injekció (ha a menekülés nem elég) < - olvassa el ezt

A szűrők megkerülhetők, és az SQL utasításokba kerülő adatok több helyről származhatnak, nem csak a felhasználói bevitelről. Az SQL által befolyásolt forrás / mosogató belépési pontjai tárolhatók (magasabb rendű), például, de egyértelműen a HTTP GET paraméterek és a HTML űrlapok POST paraméterei nem az egyetlen módja a felhasználó bevitelének. A paraméterezett lekérdezések nem feltétlenül teszik szabaddá az SQL utasításokat injekcióktól. Szükségük van változó kötésre, a karakterlánc-műveletek / összefűzés eltávolítására és bizonyos biztonsági problémák elkerülésére az SQL-záradékok széles skálájával.

A legtöbb fejlesztő elfelejti ellenőrizni harmadik féltől származó összetevőit és egyéb függőségeit is Az SQL injekcióval kapcsolatos problémák, és néha nem veszik észre, hogy ezek a beillesztések saját kódjukat sebezhetővé tehetik.

A legjobb dolog egy alkalmazásbiztonsági tanácsadó céget felvenni, amely előkészíti az alkalmazás (oka) t a gyártási készenlétre. , és képezze az appdev csapat (oka) t az alkalmazás biztonsági ellenőrzéseinek beépítéséről a folyamatukba és a fejlesztési technológiájukba

Hendrick válaszának bővítése. Könnyű elképzelni, hogy a real_escape_string varázslatos golyó, bár a valóságban nem. Láttam, hogy az emberek ezt a funkciót használják, amikor intval-t akarnak használni, vagy ehelyett egész számra vetik a bemenetet. Akkor is befecskendezheti, ha a escape sztringet rossz kontextusban használja.

Mivel az a lényeg, hogy segítsen megtanulni, hogyan kell tisztességes kódot írni, és nem csak egy receptet kell másolni, hagyok néhány tippet.

• Ha kódolási dolgokat hagyunk, az sql injekciójának sokféle módja van, és nem mindegyikhez szükséges a "vagy" vagy "hozzáadása, ezért az Addslashes alapvetően egy béna megoldás, amelyet a béna és képzetlen fejlesztők használnak .... (Azok, amelyekből nem szabad kódot olvasni).

• Ez nem sokszor fordul elő, de valójában létezik olyan vektor, ahol a támadó egy db utasításban kihasználhatja az előkészített utasításokat. Ez nem gyakori, de emlékezhet arra Az elkészített utasítás egy állítást használ, de tábla metaadatok oszlop típusával, méretével.

• Más szokásos béna hiba a lájkokkal ellátott lekérdezések kezelése ..... Ha talál hogyan működik, megtehet néhány közbeiktató dolgot ....

Végezze el a kutatását, soha ne bízzon egy bemenetben, soha ne használjon mást, csak egy elkészített állítást, ne hagyjon figyelmen kívül bárkit azt mondja, hogy használja a escape fu ...

És biztonságban kellene lenned e, ne felejtsd el, hogy nincs értelme mást szerezni, mint amire számítasz, olyan erős gépelt api a barátod;).