Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Átlátszó zsetonok

2009.07.21. 14:20 | buherator | 13 komment

Jó rég volt már jó kis böngészőhackelős poszt, igyekszem kicsit szépíteni a helyzetet:

Inferno kicsit tovább gondolta a már többször bemutatott csinos CSS hacket, melynek segítségével szépen bele lehet látni a böngészőkben tárolt előzményekbe. Az agyalás eredménye egy kliens oldali, CSRF-védelem megkerülésére szolgáló módszer lett, melynek lényege már körvonalazódhat a tájékozottabbak fejében.

A leggyakoribb CSRF elleni védelmi mechanizmus az, hogy egy véletelenszerű karaktersorozatot (tokent) biggyesztenek minden egyes elküldött HTML űrlap adatai közé, és ennek az értéknek a megfelelőségétől függően dobják el vagy dolgozzák fel a bejövő információkat. Ezek a tokenek sokszor egy egész munkamenet alatt érvényesek, így téve lehetővé a felhasználók számára, hogy az Előre/Vissza gombokat használják.

Ha azonban a token elég rövid, valamint GET paraméterként, vagyis az URL-ben kerül átadásra, akkor megfelelő mennyiségű "link" kigenerálása után a CSS előzményböngészés segítségével meg lehet tudni, hogy melyik is a megfelelő érték a sok közül az adott munkamenetben.

Inferno mérései alapján egy 5 karakteres token kitalálása nagyjából 2 percet vesz igénybe, ami ugyan nem túl hosszú idő (gondoljunk csak bele, mennyi időt el lehet tölteni egy jobb Flash játékkal), de jól mutatja a módszer korlátait: kellően hosszú véletlen értékek esetében már nem segít a nyers erő.

Mindez persze nem egy félelmetes biztonsági rés, vagy a CSRF-védelem alapjait döntögető áttörés, csupán egy jó példa arra, hogy hogyan lenne érdemes gondolkozni ebben a fránya hacker szakmában...

 

Címkék: css csrf

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Shitting Bull 2009.07.21. 18:36:12

Kívülállók számára is érthetően elmagyaráznád, hogy mi ez? :)
CSS még rémlik, bár nem kizárt, hogy egészen másra gondolok, mint amire te használod.
A CSRF totál ismeretlen.
És milyen _komoly_ problémát okozhat, ha illetéktelen oldal vissza tudja nézni az előzményeimet?
(tekintsünk el attól a kapitális baklövéstől, hogy néhány gagyi oldal az URL-be kódolja a jelszavakat)

Flashzee · http://www.flashzene.com 2009.07.21. 18:58:53

Nekem is kicsit zavaros ez az egész!

tiboru · http://blogrepublik.eu 2009.07.21. 19:35:37

@Shitting Bull:
@Flashzee:

De jó, hogy nem vagyok egyedül az értetlenkedésemmel...

   2009.07.21. 19:39:18

Pedig tök érthető. Nézzétek meg a poszt előzményét is, úgy világossá válik, mit is használnak mire. Segítség: a "CSS hacket" szavak alatt van a link.

Lord_Cica (törölt) 2009.07.21. 22:01:42

Azért van benne egy gondolati bukta.
Azokat a "zsetonokat" arra használják, hogy a vissza vagy a refresh gomb hatására ne történjen újra postolás. Ezt úgy küszöbölik ki, hogy minden oldalmegjelenítésnél generálnak egy véletlen sorozatot, amit az oldalra is betesznek (az értelmesebbek egy rejtett mezőbe, de most tegyük az url-be) és a session-ben is tárolnak. Majd post után a szerver oldalon összehasonlítjuk a rejtett mezőben küldött értéket a sessionben lévővel és ha egyezik, akkor úgy vesszük, hogy volt posztolás.
Tehát minden letöltésnél új véletlenszám generálódik az oldalon és a session-ben. (Így az előzményekben levő értékek semmire sem jók.)
Ez a módszer viszon ennek az ellenkezőjét feltételezi, amit sztem senki sem csinál, mert teljesen logikátlan.

moli 2009.07.22. 00:52:38

en erre a celre md5-ot hasznalok, az emlitett 5 karakteres az alphanumerikus?

Megdobbent 2009.07.22. 02:32:18

Ezt nagyon ki kellet ajanlania az indexnek, mert komolyan nincs ember a foldon, aki ne erdekelne...

beavereater [AT] 2009.07.22. 07:52:55

"Ezek a tokenek sokszor egy egész munkamenet alatt érvényesek,(...)"

Ilyen hülye projektvezető szvsz nincs, aki ezt jóváhagyja...

Mao elvtárs · http://diamondhostess.hu 2009.07.22. 08:33:52

@beavereater: Miert, olyan hulye projektvezeto is van, aki ezt a posztot jovahagyta az index fooldalan.

buherator · http://buhera.blog.hu 2009.07.22. 09:29:46

@beavereater: Nézd meg az iWiW-et, MyVIP-et, hogy csak két nagyot említsek, ahol ezt csinálják, bár ezeken a helyeken nem GET-ben mennek a tokenek. Talán blog.hu is így működik...

Lord_Cica (törölt) 2009.07.22. 10:20:02

@buherator: bár igaz, hogy vannak, akik a session id-t is get-ben adják át, és 5 karakter alatti (autoincrement id) :)