Webalkalmazások biztonsági tesztelése 4

A hacker tanfolyam negyedik részében a hitelesítés megtámadásával fogunk foglalkozni. 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.

A hitelesítés az esetek döntő többségében egy felhasználónév, jelszó párossal történik. Ha a user által megadott adatok egyeznek egy tárolt párral akkor a felhasználó hitelesítve van, hozzáférhet olyan adatokhoz, funkciókhoz melyekhez hitelesítés nélkül nem férne hozzá.

Jelszóválasztás

A userek hajlamosak rossz jelszavakat választani. Legalábbis egy részük. Tegyük fel, hogy csak a userek 10%-a választ könnyen megfejthető jelszót, akkor is már csak pár száz felhasználónál jelentős számú hozzáférést könnyen fel lehet törni. A valóságban az arány jóval rosszabb, sokkal több mint 10% a rossz jelszavak aránya, 50-60%-tól akár 90%-ig is elmehet. A miértekről már írtam itt.

Rossz, gyenge jelszavak a rövid jelszavak, szótári szavak, nevek, a usernévvel egyező jelszavak, és az 1234 vagy asd típusú jelszavak.

Tesztelés

Első körben teszteljük le, hogy az alkalmazás elvár-e a jelszavaktól valamit. Regisztráljunk be – ha van rá mód – és próbáljunk meg üres jelszót megadni, aztán egy 1-est, aztán a fenti gyenge jelszavak valamelyikét. Ugyanezt a tesztet megcsinálhatjuk nem csak új user létrehozásánál, hanem létező jelszavának módosításakor is, mivel előfordul, hogy az új usereknek szigorú szabályoknak kell megfelelni a jelszóválasztásnál, aztán később már arra módosítják amire akarják. A tesztelés során a hibaüzenetekből megtudhatjuk ha a rendszer mondjuk minimum 5 de legfeljebb 8 karaktert vár, ha tiltja a speciális karakterek használatát, vagy ha egyszerűen csak bármit elfogad amit a user megad. A rendszer felhasználónevekkel és jelszavakkal kapcsolatos elvárásainak feltérképezése után elkezdhetjük feszegetni az ajtót.

Brute force

A brute force (nyers erő) típusú betörések a legkevésbé kifinomultak, sokszor elég lassúak, de – amennyiben a rendszer nem védekezik a brute force támadások ellen – majdnem mindig eredményesek. A brute force támadások során a behatoló általában egy egyszerű script segítségével különböző felhasználónév, jelszó párosokat küld a bejelentkező felületnek és figyeli, hogy mikor sikerül belépni. Egyetlen egyszerű géppel, közepes sávszélesség mellett is már percenként több ezer próbálkozást lehet végrehajtani.

Általában az alap tesztekkel kezdjük, int a test, teszt, admin, demo, password, jelszó, test123, qwerty, 1234567, cégnév, majd továbblépünk a szótári szavakra és nevekre.

Ha 10 sikertelen kísérlet után sem kapunk hibaüzenetet akkor szinte biztos, hogy az alkalmazás nem védekezik a brute force támadások ellen.

Figyelnünk kell, hogy változik-e a html forrás egy sikertelen bejelentkezés után, ugyanis előfordul néha, hogy kliens oldalon szerette volna a programozó megvalósítani a brute force elleni védelmet, és rejtett html inputba tesz valami olyasmit, hogy loginattempt = 2.

Brute force támadásoknál nagy segítség ha hibás bejelentkezés esetén más hibaüzenetet kapunk ha a jelszó a hibás mintha a usernév. Ha nem akarjuk megkönnyíteni a behatolók dolgát, akkor jobb ha a “hibás usernév vagy jelszó” típusú hibaüzenetekkel dobáljuk meg a usert.

Userneveket többféle módszerrel is begyűjthetünk. Sok alkalmazás lehetővé teszi a hitelesített userek számára a többi usernév megtekintését. Aztán a regisztrációnál jelzi ha már foglalt usernevet akarunk a magunkévá tenni. Sok alkalmazás mint a fórumok, blogok pedig a bejegyzések mellett megjeleníti a userneveket. Ha kellő számú érvényes usernevet össze tudunk gyűjteni akkor egyre könnyebb dolgunk lesz a hitelesítés megtámadásában.

Védekezés

A gyenge jelszavak ellen védekezhetünk jelszó erősség mérővel. Előírhatjuk, hogy a jelszónak tartalmaznia kell kis és nagybetűket és számokat, és minimum 8 karakter hosszúnak kell lenni. Persze ezzel azt fogjuk kockáztatni, hogy a user leírja valahová a jelszavát…

Az alkalmazásunkat mindenféleképpen lássuk el brute force elleni védelemmel. A legegyszerűbb esetben szerver oldalon tároljuk az azonos forrásból (értsd IP cím + mondjuk böngésző) származó belépési kísérleteket és bizonyos számú sikertelen kísérlet után rövid időre tiltjuk a bejelentkezési lehetőséget. Az adminisztrációs hozzáféréseknél érdemes beépíteni valamiféle zárolási mechanizmust, azaz ha valaki feszegeti az ajtót, akkor a hozzáférés zárolásra kerül és csak kézzel lehet a zárat feloldani, nem oldódik fel automatikusan egy idő után.

Az alkalmazásunk biztonsági érzékenységétől függően igen kifinomult védekezési mechanizmust állíthatunk fel a brute force elleni védekezésre, de minden webalkalmazás esetén érdemes legalább a minimális védelmet biztosítani.

A következő részben további hitelesítési biztonsági kérdésekkel fogunk foglalkozni.