Webalkalmazások biztonsági tesztelése 5

Folytatjuk a hitelesítési modell támadási felületeinek és védekezési eljárásainak feltérképezését. Ahogy az előző részben már szó volt róla sok esetben az a leggyengébb láncszem és igen sokféle támadási felületet ad.

MIM

Tisztában kell lennünk azzal, hogy ha a login nem https-en keresztül történik, akkor login adatokat elkaphatja

• valaki a user helyi hálózatán
• valaki a user ISP-nél
• valaki aki hostolja az alkalmazást
• az alkalmazás működtetői.

Az ilyen típusú támadások a Men In the Middle (MIM) támadások. Ezek miatt az alkalmazásunk érzékenységétől függően érdemes a loginnál és bizonyos funkcióknál secure http-t használni.

Még https esetén is előfordul, hogy ha átirányítás is történik, akkor az átirányításnál már az azonosítók sima szövegként kerülnek kiküldésre. Ezért különös figyelmet kell fordítanunk az átirányítások tesztelésére és kezelésére.

Jelszó módosítás

A jelszó módosítási eljárások – amelyek sokszor egyáltalán nincsenek is meg – szintén a tesztelendők listáján vannak. Néha a szolgáltatás elérhető a tényleges jelszó megadása nélkül is vagy a jelszó megadás lépésének kikerülésével.

Az elfelejtett jelszó emlékeztetők több rossz modellt is megvalósíthatnak. Néha egyszerűen csak kiírják a jelszót, vagy a usernév megadása mellett beengedik a rendszerbe a támadót. A biztonsági kérdések (pl Mi az anyukád neve?) csak nevükben biztonságiak, általában sokkal könnyebben kitalálhatóak mint maga a jelszó. A password hintek (Pl a jelszó az apukám neve) szintén csak könnyebbé teszik a támadók dolgát.

Jobb megközelítés amikor e-mailben kiküldünk egy egyedi URL-t amin keresztül a user módosíthatja a jelszavát. Itt figyelni kell, hogy az egyedi URL valóban egyedi legyen és ne valami kitalálható vagy szekvenciális URL legyen.

Emlékezz rám

… csak egy cookie ami tartalmazza a jelszót is …

Személy szerint a kedvencem az emlékezz rám funkció. Nagyon sokszor egy olyan cookie-n keresztül van megoldva amely tartalmazza a usernevet és a jelszót is. Innen már csak a cookie-t kell megszereznünk és bent is vagyunk. Alap követelmény minden emlékezz rám esetében, hogy a jelszó ne legyen benne sem simán, sem kódolva sem sehogy. Jó esetben valami állandóan változó érték segítségével van megoldva mint pl az utolsó bejelentkezés időbélyege, megsózva és titkosítva.

Megszemélyesítés

Sok admin felületen vannak user megszemélyesítő funkciók amely segítségével az adminisztrátor valamelyik user bőrébe bújhat, azaz azt látja amit a user látna. Sok ilyen megvalósításnál ezt egy alapértelmezett jelszó használatával érik el. Azaz egy kulcs ami minden zárt nyit.

Azonosítók gyenge ellenőrzése

Vannak olyan hibák is amikor az ellenőrzésnél például csak a jelszó első 5 karakterét ellenőrzik a teljes jelszó helyett. Előfordul, hogy az ellenőrző algoritmus nem tesz különbséget kis és nagybetűk között, vagy kiszűri a speciális karaktereket. Mindezek szűkítik az érvényes jelszavak halmazát és így könnyebbé teszik az illetéktelen behatolást.

Egyéb hitelesítési gebaszok

A fentieken kívül sok más típushibát fedezhetünk fel a hitelesítési eljárások megvalósításában. Például kezdeti jelszavak kiosztása a usereknek úgy hogy a kezdeti jelszó mindenkinél azonos (sokan nem fogják soha megváltoztatni), könnyen kitalálható (pl 001, 002, 003), vagy a felhasználónévvel azonos. Pár tíz új regisztrációval egy támadó könnyedén meghatározza, hogy az előtte illetve utána regisztrálók milyen kezdeti jelszót kaphattak.

Egy másik hiba amely sokkal sokkal többször előfordul mint azt gondoltam volna a hitelesítési adatok nem biztonságos tárolása, azaz a jelszavak sima szövegként való eltárolása az adatbázisban. Ostobaság azt gondolni, hogy aki hozzáfért az adatbázishoz az már úgy is tud mindent, akkor meg minek titkosítsam a jelszavakat. Egyrészt néha az adatbázis adataihoz elég könnyen hozzá lehet férni, másrészt pedig a userek nagy százaléka jó eséllyel ugyanezt a jelszót fogja máshol is használni. Vagyis a saját figyelmetlenségünkkel ajtót nyitni más rendszerekbe is nem éppen a legmegfelelőbb.

Végezetül csak a hitelesítési problémákat boncolgató előző rész első gondolatát szeretném ismét itt megjeleníteni: A weblapok mintegy 67%-ánál található valamiféle biztonsági rés ezen a területen. Valójában a hitelesítés a védekezés frontvonala, de ennek ellenére sokszor a leggyengébb láncszem is.