ugrás a tartalomhoz

sql smuggling

boris · 2009. Okt. 19. (H), 17.31
Sziasztok.
Nem rég olvastam az sql smugglingról. Eddig nem ismertem ezt a támadási formát, azt olvastam, hogy utf-8as kódolás mellett nem véd a sql injection által használt betörések kivédése. Tehát az idézőjel stb escapelése.
Hogyan tudnék védekezni az ilyen fajta támadások ellen? És pontosan hogy is működik az sql smuggling.
Előre is köszönöm a válaszokat
‹ többdimenziós tömb in_array vizsgálata egymásba ágyazott function ›
 ■
1

link

Szekeres Gergő · 2009. Okt. 20. (K), 10.57
itt találsz több információt róla:

link
2

Miről van szó?

janoszen · 2009. Okt. 20. (K), 12.09
Most itt arról van szó, hogy a több bájtos karakterek tényét kihasználva "kitoljuk" a string vége jelet? Erre a karakterkódolás-függő escape függvények (pl mysql_real_escape_string) megoldást nyújtanak...
3

ansi -> utf

Szekeres Gergő · 2009. Okt. 20. (K), 14.25
csak gyorsan tudtam átfutni a linkelt pdf-et, én valami olyasmit vettem ki belőle, hogy ha a felhasználó beír egy szöveget mondjuk arabul, akkor az nyilván (az escapelést leszámítva) egy az egybe bekerül a lekérdezésbe. Viszont az megpróbálja átkonvertálni az adatbázis karakterkészletére, mégpedig aszerint, hogy melyik karakter mire hasonlít. Ha valaki ott beír pont egy olyan karaktert, amint az adatbázisszerver '-re konvertál, akkor ugyan ott vagyunk, mintha nem escapeltük volna az inputot. De javítsatok ki ha tévedek... :)
4

Nem

janoszen · 2009. Okt. 20. (K), 14.58
A konverzió elvileg csak akkor probléma, ha két különböző karakterkódolás van a játékban. Homogén UTF-8 esetén sem ennek, sem a byte kitolásnak nem kéne problémának lennie.
5

Real

gphilip · 2009. Okt. 20. (K), 15.26
Annyit fűznék hozzá, hogy a mysql_real_escape_string használata javasolt minden esetben a mysql_escape_string helyett, mert az előbbi figyelembe veszi a mysql kapcsolat katakterkódolását is, és ez alapján végzik az escape-elést.
6

Vihar a bilien

vbence · 2009. Okt. 20. (K), 16.54
Mindenhol hallotam riogatni az UTF-8 és az injection kapcsolatáról, eddig az idétett PDF volt az egyetlen ahol hajlandók voltak vlami konkrétumot is mondnai az ügyben. Azonban...

Ha egy DBMS saját belső konverziójában transzliterál (hasonló kerekterrel helyettesíti azokat amik nem reprezentálhatók a cél kódolásban), az az adott szoftver súlyos biztonsági problémája, és bármilyen opensource projektben azt megfelelő súllyal fogják kezelni miután jelented nekik. Mysqlben például (a pdfben példának használt karakterrel) a következő query eredménye (utf-8 kapcsolaton keresztül):
SELECT CONVERT(_utf8'asdʼasd' USING latin1);
természetesen asd?asd lesz. A MySQL nem fogja saját szakállára a hasonló ' karakterre cserélni a latin1-ben nem szereplő ʼ karatert.

Amit én veszélynek gondolok az az UTF-8 kódolás redundáns lehetőségeinek kiaknázásában rejlik. (Párosítva a gondatlan, UTF8-cal nem számoló input ellenőrzéssel és egy megengedő konvertáló algoritmussal).

A konkrét példa

Az aposztróf hexa kódja 0x27 (decben 39). Ez az első 128 karakter része az ASCII táblában (vagyis a Unicode-ban is). Ez a karater nem lesz escape-elve, tehát UTF-8 reprezentációja is megegyezik az ASCII-val, így bármilyen ASCII-alapú szűrőn fennakad.

A wikipédia táblázatát átnézve feltűnhet a rendszerben rejlő redundancia, vagyis hogy a 0x80-0x7ff régió kódolására használt sémát (vagy az ennél nagyobbakat) alkalmazhatjuk a 0x80-nál alacsonyabb kódok tárolására is.

Így a (0xc0, 0xa7) bájtsorozatot dekódolva a 0x27 ascii kódot kapjuk. (Ha jól számoltam). Ez a két byte símán átcsusszan egy ASCII alapú szűrőn.

A harmadik láncszem egy buta konvertáló algoritmus lenne, aminek nem tűnik fel, hogy a kódolt karakter nem abban a régióban van amire az adott séma vonatkozik. Lehet próbálkozni, ki talál ilyet.. :) Az ICONV torkán nem sikerült lenyomni. A MySQL CONVERT főggvényével sem sikerült eddig:
 SELECT CONVERT( CONCAT( CHAR( 0xc0 ) , CHAR( 0xa7 ) ) USING utf8 ) ;