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...
Shitting Bull 2009.07.21. 18:36:12
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
tiboru · http://blogrepublik.eu 2009.07.21. 19:35:37
@Flashzee:
De jó, hogy nem vagyok egyedül az értetlenkedésemmel...
FallingStar 2009.07.21. 19:36:33
2009.07.21. 19:39:18
dnet 2009.07.21. 21:20:10
en.wikipedia.org/wiki/Cross-site_request_forgery
Lord_Cica (törölt) 2009.07.21. 22:01:42
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
Megdobbent 2009.07.22. 02:32:18
beavereater [AT] 2009.07.22. 07:52:55
Ilyen hülye projektvezető szvsz nincs, aki ezt jóváhagyja...
Mao elvtárs · http://diamondhostess.hu 2009.07.22. 08:33:52
buherator · http://buhera.blog.hu 2009.07.22. 09:29:46
Lord_Cica (törölt) 2009.07.22. 10:20:02