Webalkalmazások biztonsági tesztelése 3

csirkeHacker tanfolyamunk harmadik részében megkezdjük a támadási és tesztelési módszerek ismertetését. Elsőként a kliens oldali ellenőrzéseket próbáljuk meg kijátszani. A fő szabály amit webfejlesztőként meg kell tanulnunk, hogy a kliens oldali ellenőrzések kizárólag kényelmi eszközök és semmiféleképpen nem alkalmasak biztonsági előlapnak. Ennél fogva mindennemű kliens oldali ellenőrzést meg kell ismételni szerver oldalon is.

Mi is az a kliens oldali ellenőrzés?

Vegyünk példaként egy weblapot amelynél a regisztrációnál meg kell adnunk az email címünket. Ma már elvárható, hogy ha valós e-mail címet akarunk megkapni akkor egy kis JavaScript kóddal leellenőrizzük, hogy az e-mail cím megfelelő formátumú-e és az esetleges hibáról a usert az oldal újratöltése nélkül értesítsük.

Hogyan támadható meg?

A kliens oldali ellenőrzést rendkívül egyszerű megtámadni, ahogyan azt majd a későbbiekben látni fogjuk. Sikeres támadást azonban csak akkor tudunk végrehajtani, ha a kliens oldali ellenőrzést az alkalmazás nem hajtja végre a szerver oldalon is.

Hidden inputok

Sokszor előfordul, hogy a szerver a html válaszban kiküld olyan adatot amelyet a kliens ténylegsen nem használ fel, csak visszaküldi a szerver felé. Ilyen lehet például egy webshopban megrendeléskor a termék ára, amely megjelenik egy hidden inputban. Ha a szerver a hidden input értékét használja a tényleges kalkulációhoz, akkor a hidden értéket átírva 1 Ft-ért is hozzájuthatunk a kiválasztott termékhez.

Hidden értékként megjelenhet egy kedvezmény %-os mértékkel, vagy akár letölthető árucikkek esetében az, hogy fizettünk-e már. Amennyiben a szerver oldalon az alkalmazás megbízik ezekben az adatokban akkor könnyű dolgunk van.

Hidden mezők hiányában – vagy ezek helyes szerver oldali kezelése esetén megpróbálkozhatunk nem várt értékek megadásával. Maradva a megrendelős példánál néhány rosszul kivitelezett alkalmazás esetében ha negatív darabszámot vagy árat adunk meg akkor akár pénz jelenhet meg az alkalmazásban lévő számlánkon.

Egyéb helyek

Ugyanezen adatok megjelenhetnek cookie-ban, url paramétrben, http referer headerben is, így ezeket is érdemes megvizsgálni és kipróbálni, hogy hogyan is reagálnak az átírásokra.

Kódolt értékek

Valamikor a fejlesztők felismerve ezt a problémát trükkös, titkosított formában adják meg ezeket az érzékeny adatokat. Például a termék ára benne van a hidden mezőben, a szerver ez alapján számol, de a forma kódolt, például egy termék ára fg254_d lesz. Általánosságban elmondható, hogy ezek többnyire elég egyszerűen visszafejthetők, másrészt pedig ha megkeressük a legolcsóbb terméket és annak árát adjuk meg a hidden input értékeként, akkor már visszafejtés nélkül is nyert ügyünk van.

Maxlength

Érdemes külön figyelmet szentelnünk az inputok maxlength tulajdonságának is. Sok sikeres XSS támadást, XSS beoltást, és buffer overflow támadást hajtottak már végre a segítségükkel. Vegyünk egy inputot ami elfogad bármilyen karaktert, de a maxlength tulajdonsága mondjuk 8-ra van állítva. A maxlength tulajdonság miatt ugye nem fogunk tudni egy XSS támadást végrehajtani mivel túl kicsi a rendelkezésre álló karakterszám. Azonban a maxlength értékét bármikor meg tudjuk változtatni, és ha a szerver oldalon nincs újra ez ellenőrizve akkor máris nyitva a kapu sokféle csúnyaság előtt.

Script alapú ellenőrzés

Kifinomultabb ellenőrzéseket időnként JavaScripttel hajtanak végre. Ezeket kétféleképpen is kiiktathatjuk. A legkézenfekvőbb megoldás a JavaScript kikapcsolása és ezzel mindennemű JavaScript funkció ignorálása. A másik, hogy fogjuk az ellenőrző metódusokat és lecseréljük a sajátunkra, amelyek minden esetben igazat adnak vissza. Így vagy úgy, de ha a szerver oldalon nincs ellenőrzés, akkor itt sikert érhetünk el.

Disabled inputok

A disabled inputokat a formok elküldésekor a böngészők ignorálják, azaz nem küldik el a szerver felé. Azonban jelenlétük arra utal, hogy bizonyos körülmények között (például adminoktól) a szerver elfogadja őket. Az is előfordulhat, hogy régebben normál inputként működtek, aztán valamilyen módosítás után már nem volt rájuk szükség. Ettől függetlenül előfordul, hogy a szerver elfogadja és feldolgozza őket. Ezek teszteléséhez nem kell mást tennünk mint a disabled tulajdonságot levenni az adott mezőről.

Appletek

A java appletek letöltődnek és olyan eszközökkel mint a jad vagy a jode vissza lehet őket fejteni, módosítani majd újra futtatni. Ezen kívül a public metódusok elérhetőek JavaScriptből.

Flash

A flash visszafejtésére is több eszköz van, melyek közül az egyik legnépszerűbb a flashm. A visszafejtett kód szintén módosítható és futtatható.

Háttér adat kommunikáció

Mind a flash, mind az appletek, de ezeken felül az activex vagy éppen a javascript is szívesen kommunikálgat a háttérben a szerverrel. Ha figyeljük ezeket a hívásokat és válaszokat akkor néha érdekes adatokat láthatunk és módosíthatunk.

Támadási eljárás

A fenti módosításokat többféle módon is végrehajthatjuk. Az egyik módszer a lap elmentése a saját gépünkre és ennek a másolatnak a módosítgatása, majd böngészőben való meghívása. A másik lényegsen kényelmesebb módszer a Firebug Firefox kiterjesztés használata.

Célpontok

A fentiek szerint a következőket támadhatjuk meg: hidden (vagy éppen nem rejtett) input elemek, cookie, url, referer, maxlength attribútum, JavaScript metódusok, disabled inputok.

Hogyan védekezzünk

Fejlesztőként az ilyen jellegű támadási felületeket úgy tudjuk lezárni, hogy minden ellenőrzést megismételünk a szerver oldalon is. Így még ha a kliens oldalon a rosszcsont user módosít is valamit a szerver ki fogja szűrni a problémás adatokat.

2 thoughts on “Webalkalmazások biztonsági tesztelése 3

  1. Pingback: WebMánia » Webalkalmazások biztonsági tesztelése 7

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.