Webalkalmazások biztonsági tesztelése 6

A session / munkamenet kezelés minden webalkalmazás alapvető eleme. Mivel a http kommunikáció állapot nélküli a session segítségével azonosítjuk a usereket a munkamenet során. E nélkül minden egyes oldalletöltéskor újra és újra be kellene kérni a jelszavát. Azonban a gyengén megvalósított session kezelés tágra tudja nyitni az ajtót az illetéktelen behatolók előtt.

A session kezelés támadásával bejuthatunk a webalkalmazásokba mint normál user vagy mint egy privilegizált felhasználó adminisztrátori jogokkal.

Munkamenet alapok

A user az oldal első letöltésekor vagy a bejelentkezéskor kap egy egyedi azonosítót. Ezután minden egyes oldalletöltéskor a kliens elküldi a szerver felé ezt az azonosítót. Ennek az azonosítónak a kliens oldalon való tárolása a legtöbb esetben egy cookie-ban történik.

Támadási lépések

Első lépésben azt kell megállapítanunk, hogy mely cookie érték / értékek a session azonosító. Ehhez navigáljunk egy “adataim” vagy hasonló csak bejelentkezés után elérhető részhez és egyesével távolítsuk el a különböző cookie értékeket. Minden egyes érték eltávolítása után frissítsük az oldalt. Amelyik után a rendszer kidob, azaz azt jelzi, hogy nem vagyunk bejelentkezve valószínűleg az lesz a session azonosító.

Gyengén megoldott session azonosító generálás

A session azonosító a user névből, jelszóból vagy valami más adatból képződik és esetleg kódolva van. Például egy user=rrd;jog=admin;lejarat=2010.12.31 string és hexa kódolva van.

Próbáljuk meg az azonosítót vagy erre utaló részét visszafejteni base64, xor vagy hexa kódolással.

Fogjuk a session azonosítót és kezdjük byte-onként vagy karakterenként módosítani. Ha a session nem szakad meg az első próbálkozásnál akkor az azonosítónak csak egy része szolgál az azonosításhoz, a többi valószínűleg csak só, vagy kiegészítő adat. Egy-egy ilyen módosításnál az is előfordulhat, hogy hirtelenjében egyszer csak valaki más bőrében találjuk magunkat.

Regisztráljunk be mint “a”, “aa”, “aaa”, “b”, stb és vizsgáljuk meg, hogy a session azonosítóban felfedezhető-e valamiféle minta ami visszavezethető a usernévre.

Ha a fentiek közül valahol sikert értünk el akkor brute force-oljuk a valószínűleg életképes session azonosítókkal valamelyik azonosításhoz kötött oldalt.

Megjósolható session azonosítók

Ebben az esetben a session azonosítókban nincs semmiféle értelmes adat, de az egymás után előálló azonosítók valamiféle mintát követnek.

Az olyan eszközökkel mint a Burp Intruder tesztelhetjük ez úgy, hogy a session azonosító két utolsó karakterét módosítjuk és megnézzük, hogy kapunk-e élő sessiont.

Időpont függő session (részeket) is találhatunk melyeket új session azonosítók kiadásának kikényszerítésével tesztelhetünk.

A fentiekhez kérjünk le pár száz új session azonosítót és keressünk benne mintákat a Burp-pal vagy a Webscarab-bal.

Gyenge session kezelés

Ha az alkalmazásunk egy része vagy egésze nem https mögött csücsül akkor a session azonosítók elkaphatóak egy MIM támadással.
Ellenőrizzük, hogy a session azonosítók ne kerüljenek bele a logokba vagy az url-be.

Ne engedjük, hogy ugyanahhoz a userhez egyszerre több élő session is tartozzon. Jelentkezzünk be azonos usernévvel két különböző böngészőről, számítógépről vagy IP címről és nézzük meg, hogy a webalkalmazás életben hagyja-e az első session azonosítót a második vagy harmadik létrejötte után.

Gyenge session megszakítás

Lehet, hogy triviális kijelentésnek tűnik, de legyen az alkalmazásunkban egy logout funkció.
A logout gyilkolja le a sessiont, ne csak a cookie-t törölje. Ezt le tudjuk tesztelni úgy, hogy fogjuk a session azonosítót és logout után visszaírjuk a cookie-ba. Ha ezután a session újra életre kel, akkor a session megszakítás nem biztonságosan van megoldva.

Próbáljuk ki, hogy a cookie lejárati idejétől függetlenül mennyi idő lejárta után hal el a session. Az általános javaslat 10 perc. A Burp segít ennek a tesztelésében is.

Kliens oldali session lopás

A fenti módszereken kívül a kliens oldal bevonásával is szerezhetünk élő session azonosítókat és használatukkal belebújhatunk mások bőrébe. Az XSS, a session fixálás és az xsfr használatával könnyedén juthatunk élő session azonosítók birtokába.

Szabatos cookie kezelés

A cookie-k elérését állítsuk a lehető legszorosabbra.
A domain szinten ha a józsibácsi.blogter.hu a cookie-kat a blogter.hu domainként határozza meg akkor a pirinéne.blogter.hu-ra is kiküldésre kerülnek, amit nem feltétlenül akarunk.
A path legyen konkrét. A /app path esetében a cookie elérhető lesz a /apps a /apptest, /apple és minden más azonos kezdetű elérési út esetében. Tehát helyesen /app/-ot kell megadnunk path-ként.

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

  1. A phpsessid alapból valami random cuccnak az md5 kódolása. Néhány php ini paraméterrel át lehet hangolni, hogy ne phpsessid, hanem jsessionid legyen a neve, meg ne md5, hanem sha kódolású legyen, és tartalmazzon mondjuk egyéb karaktereket a 0-9a-f-en túl is.

    És ez csak az alap. Ha ehhez még lecseréljük az egész session-kezelő réteget úgy, hogy a fent említett ellenőrzéseket is tartalmazza, már elég sokmindent kivédhetünk.

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.