Szerző Téma: Script injection, XSS, SQL injection - avagy hogyan védjük weboldalainkat  (Megtekintve 1764 alkalommal)

Nem elérhető Fantasy™

  • Intermediate
  • **
  • Thank You
  • -Given: 52
  • -Receive: 38
  • Hozzászólások: 156
  • Segített: 20
Ezt az írást elsősorban webfejlesztőknek ajánlom figyelmébe, akik szeretnék weboldalaikat komolyabban levédeni hekkerek vagy botok ellen.

A címben szereplő 3 kifejezés valószínűleg a legelterjedtebb támadási formák manapság weboldalak ellen. Egy valamirevaló webprogramozó minimum ezek ellen kőkeményen védekezik, és akkor a Greasymonkey hack-ekről és társaikról még nem is beszélünk.

Az XSS, azaz Cross-site-scripting például kiválóan alkalmas Phising-ra (magyarul adathalászatra, de egy ügyes hekker szinte akármire fel tudja használni, gondolok itt a sütilopástól kezdve a személyes adatok logolásáig és a CSRF-ig mindenre). Itt egy példa nem perzisztens XSS támadásra:

Vannak olyan oldalak, ahol egy felhasználónak szánt üzenetet, ERROR_MESSAGE-t, vagy SUCCESSFUL_MESSAGE-t a programozó GET-es változókban utaztat, pl: http://tedomained.hu/feltoltes.php?mess=Sikeres%20feltoltes!

Ezt általában egy az egyben kiírják a programozók a weboldalra, nem figyelve a biztonságra, hiszen mi van akkor ha átírom a GET-es változót, valahogy így: http://tedomained.hu/feltoltes.php?mess=<script>alert(1);</script> ?

Ekkor a böngésző simán az arcunkba tolja az alert ablakot, tehát találtunk egy módszert, hogyan juttassunk ártó szándékú javascriptet egy más által birtokolt weboldal forráskódjába. A legjobb védekezés az, ha elkerüljük az URL-ekben szállított stringeket, inkább használjunk azonosító integereket (pl 1,2,3 stb), aminek mindegyikéhez tartozik egy felhasználói üzenet, majd egy switch-el döntjük el, melyik üzenetet kapja a juzer, és már be is foltoztuk a biztonsági rést. Ha mégis ragaszkodunk az URL-ben szállított stringekhez, akkor viszont kiírásnál ügyeljünk rá, hogy egy strip_tags-et, vagy egy htmlentities-t engedjünk rá előtte.

A Script injection hasonlít kicsit az XSS-re, azzal a külömbséggel, hogy ez már gyengébb adatbiztonsági ismereteket feltételez a weboldal programozójáról. Arról van szó, hogy egy felhasználó által megadott input mezőbe ha HTML,JavaScript, vagy egyéb a böngésző által lefordítható kódot injektálunk, és ez kiírásra kerül magunknak (vagy ami még rosszabb: más felhasználóknak), akkor szintén az a helyzet áll fenn, hogy más által írt weboldalba simán ártó szándékú kódot varázsolhatunk. Egy social networknél például kifejezetten gáz lenne egy ilyen jellegű hiba ;).

Védekezés: szintén strip tags, vagy htmlentities, lehetőleg már adatbázisba írás előtt.

Az SQL injection főként keresésnél, vagy jelszómódosításnál tud kifejezetten veszélyes lenni (valójában talán a legveszélyesebb mind közül). Maradva a social network példánál, képzeljük el a jelszómódosító FORM-ot, és azt, hogy mi megy a háttérben:

Van 2 input mező, mindkettőbe ugyanazt a jelszót kell beírni, és ha egyeznek, a szerver oldali script kicseréli az adatbázisban a jelszót, majd küld egy message-t, hogy "sikeres jelszócsere". Nézzük meg, hogyan néz ki ez az PHP-SQL utasítás:
mysql_query("UPDATE felhasznalok SET jelszo='uj_jelszo' WHERE nev='RobbeR'");
Ebben ugye a WHERE feltétel mondja meg az adatbázisnak, hogy csak abban a sorban cserélje a jelszót, ahol a név='RobbeR'. (vagy 'id=[0-9]*', attól függ, mi a UNIQUE mező az adatbázisban). De mi van akkor, ha én jelszónak ezt adom meg: jelszo'--   ... Ekkor ez lesz a lekérdezésből:
mysql_query("UPDATE felhasznalok SET jelszo='jelszo'--' WHERE nev='RobbeR'");
Ehhez tudni kell, hogy SQL-ben a megjegyzés a '--' után írandó, tehát ez a string 2 részre szedi az utasítást:
UPDATE felhasznalok SET jelszo='jelszo' és --' WHERE nev='RobbeR'
ahol a 2. rész ugyebár megjegyzés, így valójában csak az első rész lesz értelmezve az adatbázison. Ebben meg már nincs benne a feltétel, így nem csak azt az egy sort írja át, hanem az összes sort a `felhasznalok` táblában. Ha ezt egy social network-ön alkalmazzák sikeresen, akkor ezután mindenkinek 'jelszo' lesz a jelszava, függetlenül attól hogy eddig is az volt-e, vagy nem. Ez azért elég gáz tud lenni, ha pl nincs mentve az adatbázis...

Védekezés: mysql_real_escape_string, ami escapeli az összes ' vagy " karaktert, illetőleg a \ karaktereket is.

Sok sikert a fejlesztésben, remélem azért valaki elolvassa ezt, és hasznosnak találja majd;)