Webalkalmazások biztonsági tesztelése 4
biztonság, hogyan
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.
Ez a bejegyzés rrd billentyűzetéből potyogott ki 2010 február 26. napján 16:30:10-kor. Eddig 863 olvasást ért meg. A visszajelzéseket nyomonkövetheted ezzel az RSS feed-el. Véleményt nyilváníthatsz, vagy trackbackolhatsz a saját oldaladon.
JólMegMondjad!
7 vélemény
-
bh
2010 március 1. 11:32:15A cikk tetszik, de lenne néhány megjegyzésem. Számomra elvesznek a pici részletek, valahogy jobban kéne tagolni a szöveget.
A napokban találtam pontosan erre a részre egy remek példát: “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.”
Akit érdekel, látogasson el az ingatlan.com-ra. Mivel partnerünk, csak úgy poénból megnéztem az oldalukat, az alap biztonsági rések után kutatva. Pár perc alatt a belépésnél máris egy általános hiba, ami a fenti idézetre egy tipikus példa.
-> Fent belépés majd “Offce-os partner”. Egy-két próbálkozás alatt a “balazs” felhasználónevet sikerült eltalálni és már csak egy jelszó kéne hozzá… Kipróbálás során látható, hogy értesülünk a helytelen felhasználónévről, de amint az helyes már csak a jelszóra ír hibá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.”
Ez valóban hasznos és egyszerű. Hamisítani sem olyan túlságosan nehéz. Hasznos lehet a szintén egyszerű CAPTCHA, amit természetesen szintén nem lehetetlen feltörni, de mindenképpen nehezebb mint az előbbi módszer. -
rrd
2010 március 1. 12:31:14@bh Köszönöm az észrevételt, igyekszem jobban tagolni. A captcha meg szerintem az egyik lehető legrosszabb dolog ami bemászott az internetre. Persze ez csak egyéni vélemény.
-
bh
2010 március 1. 12:50:14Megindokolnád miért gondolod így? Nem mintha én a captcha követője lennék, csupán érdekelne a véleményed.
-
rrd
2010 március 1. 12:59:52@bh A netezők 30%-ának van valamiféle látászavara (színtévesztő, szemüveges, stb). Többségüknek problémás a captcha visszafejtése. Az egyszerűeket géppel is egyszerű visszafejteni, a bonyolultakat pedig szerintem emberek már meg sem tudják fejteni. Ki kéne találni valamit helyette, ami ember barátabb.
-
bh
2010 március 1. 13:03:45Így már értem az állaspontod, teljesen igazad van.
-
bh
2010 március 1. 13:10:20Bár létezik olyan megoldás is, hogy gombnyomásra felolvassa a szöveget.
Engem az zavar igazán, hogy nagyon lelassítja a procedúrát. Amíg az ember elolvassa, begépeli, ha rossz akkor újra…
-
deejayy
2010 április 26. 08:09:12Captcha: rejtett mezők, javascript, amiket a robotok 99%-a (?) nem tud értelmezni.




