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.
A 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.
@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.
Megindokolnád miért gondolod így? Nem mintha én a captcha követője lennék, csupán érdekelne a véleményed.
@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.
Így már értem az állaspontod, teljesen igazad van.
Bá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…
Captcha: rejtett mezők, javascript, amiket a robotok 99%-a (?) nem tud értelmezni.
Nagyon jó!!!!!!