HTML

RobbeR tech és magánblogja

kontakt:RobbeR at RobbeR pont hu

Egyéb publikálások: Elte-IK blogja
saját weboldal: RobbeR.hu

Webisztán

Nincs megjeleníthető elem

Címkék

Indafotós képek

Friss topikok

Linkblog

Script injection, XSS, SQL injection - avagy hogyan védjük weboldalainkat

2008.06.25. 12:56 RobbeR

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;)

1 komment

Címkék: tech javascript hack php

-->

A bejegyzés trackback címe:

https://robber.blog.hu/api/trackback/id/tr5538666

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

zsoltit · http://instantscamalert.com/ 2011.02.17. 15:59:04

Jol nyomod, jo volna tudni programozonyelven!
De majd talan egyszer :)
süti beállítások módosítása