Wikipédia

Cross-site request forgery

A cross-site request forgery, más néven one-click attack, session riding, rövidítve CSRF vagy XSRF (magyar fordításban kb. oldalon-keresztüli kéréshamisítás), egy exploittípus, ahol a weboldalaknak küldenek nem-autorizált parancsot a felhasználóként, amelyben megbízik az oldal.[1] A cross-site scripting-gel (XSS) ellentétben, amely a felhasználó weboldalba vetett bizalmát használja ki, a CSRF a weboldal a felhasználóba (és böngészőjébe) vetett bizalmát.

Háttere szerkesztés

A CSRF támadhatóságok ismertek és néhány esetben kihasználtak, 2001 óta.[2] Mivel ezeket egy felhasználó IP-címéről hajtják végre, néhány weboldal-log nem rendelkezik a CSRF-re utaló bizonyítékokkal.[1] A CSRF exploitokat ritkán jelentetik meg, legalábbis nyilvánosan, 2007-ben[3] alig pár jól dokumentált példa volt. Az eBay Internet Auction Co.-jának körülbelül 18 millió felhasználója Koreában az Auction.co.kr -en személyes információkat vesztett el 2008 februárjában[4] egy CSRF támadás miatt. Egy mexikói bank ügyfeleit 2008 elején e-mailben támadták, egy kép linkjével. A képben levő link kicserélte az ADSL routerükben a bank DNS-ét egy, a bankot utánzó hamisított weboldaléra.[5]

Példák és karakterisztikák szerkesztés

 
Egy National Vulnerability Database oldal, egy CSRF sebezhetőség leírásával

A támadás alapja egy olyan link vagy szkript weboldalba ágyazása, amely elér egy oldalt, ahol a felhasználó biztosan (vagy sejthetően) be van jelentkezve.[6] Példának okáért az egyik felhasználó, Bob, böngészhet egy fórumot, ahol egy másik felhasználó, Fred, elküldött egy üzenetet. Tegyük föl, hogy Fred kialakított egy HTML img (kép) elemet, amely Bob bankjának a weboldalán egy cselekvésre mutat (egy képfájl helyett), például:

<img src="http://bank.example.com/atutal?kitol=Bob&mennyit=1000000&kinek=Fred">

Ha Bob az autentikációt egy HTTP-sütiben tartja, továbbá ha az a süti még nem járt le, abban az esetben Bob webböngészőjének kísérlete a kép betöltésére el fogja küldeni az átutalást a sütijével, ezáltal engedélyez egy tranzakciót Bob valódi engedélye nélkül.

Az alábbi karakterisztikák gyakoriak a cross-site request forgery esetében:

  • Olyan oldalakat vonnak be, amelyeknél a felhasználónak van online identitása
  • Kihasználja a weboldalt, hogy megbízik az identitásban
  • A felhasználó böngészőjében a céloldalra történő HTTP-kérések küldését éri el
  • Olyan HTTP kéréseket von be, melyeknek negatív oldalaik vannak

Az olyan webalkalmazások vannak kockázatban, amelyek a megbízhatónak tartott és autentikált felhasználók esetleges hozzájárulása nélkül követnek el nevükben cselekvéseket, nem ellenőrizve, hogy a felhasználó cselekedett-e. Egy olyan felhasználó, akinek adatait egy sütiben tárolja a weboldal és azzal is autentikálja őt, a tudta nélkül küldhet HTTP lekéréseket egy weboldalnak, amely megbízik benne és ezáltal nem kívánt cselekvést érhet el.

A CSRF támadásokat gyakorta az img (kép) HTML-elem src (forrás) címkéjén keresztül, internetes fórumokból követik el, ahol a felhasználók posztolhatnak képet, de JavaScriptet nem.

A CSRFtámadásokat gyakran az XSS támadásokkal párban használják ki, amely által a CSRF támadásokat még veszélyesebbé tehetik. Egy XSS sebezhetőség létezése igencsak gyakran lehetővé teszi a létező CSRF-ellenes cselekvések nagy részének megkerülését. Ilyen példákat ít lr az "XSS & CSRF: Practical exploitation of post-authentication vulnerabilities in web applications" publikáció.[7]

Limitációk szerkesztés

Számos dolognak egyszerre teljesülnie kell ahhoz, hogy a cross-site request forgery végrehajtódjon és sikeres legyen:

  1. A támadónak egy olyan weboldalt kell támadnia, amely vagy nem ellenőrzi a referer fejrészt (amely gyakori) vagy egy olyan áldozatot találnia, amely böngészőbeli vagy kiegészítőbeli sebezhetőség miatt engedi a referrer spoofing-ot (ez ritkább).
  2. A támadónak a céloldalon muszáj találnia egy űrlapbeküldést vagy egy negatív oldalakkal rendelkező URL-t, amely valamit csinál (például pénzt utal vagy megváltoztatja az áldozat e-mailcímét és jelszavát).
  3. A támadónak az űrlap vagy az URL inputjainak minden értékét helyesen meg kell határoznia; ha bármelyik is szükséges titkos autentikációs értékként, vagy IDként, amit a támadó nem tud megtippelni, a támadás nem lesz sikeres.
  4. A támadónak az áldozatot olyan oldalra kell csalnia, amely tartalmazza a veszélyes kódot, miközben az áldozat bejelentkezett a céloldalra.

Megjegyzendő, hogy a támadás "vak", azaz a támadó nem látja, hogy az áldozatnak a weboldal mit küld vissza a lekérésre válaszul, hacsak nem használ ki egy cross-site scripting (XSS) sebezhetőséget avagy egy másik bugot a cél weboldalon. Hasonlóan, a támadó csak olyan az eredeti hamisított kérés után megjelenő linkeket vagy űrlapelküldéseket támadhat meg, amelyek hasonlóan kiszámíthatók, mint az eredeti hamisított kérés. (További célok vezethetők be több kép használatával az oldalon vagy pedig egy, a "kattintások" közti késleltetést létrehozó JavaScript-tel.)

Ezen kényszerek miatt a támadónak nehézsége lehet a bejelentkezett áldozatok vagy támadható űrlap-bejegyzések megtalálására. Ezzel ellentétben viszont a támadások könnyen megvalósíthatók, láthatatlanok az áldozatok számára, továbbá az alkalmazásprogramozók kevésbé ismerik a CSRF támadásokat, így kevésbé is felkészültek rájuk, mint, példának okáért a jelszókkal kapcsolatos szótárakat használó támadásokra.

Súlyosság szerkesztés

A United States Department Of Homeland Security adatai alapján a legsúlyosabb CSRF sebezhetőség, amire valaha is rábukkantak a 909. a szoftverekben található bugok között a súlyosság rangsorában, amely ezt a legtöbb túlcsordulásos támadásnál súlyosabbá teszi.[8] Más súlyossági méréseket kiadtak olyan CSRF támadásokra, amely távoli kódfuttatást tesz lehetővé, root jogokkal,[9] továbbá olyat is, amely tanúsítványokat hamisít, ezáltal egyes nyilvános kulcsú infrastruktúrákat aláás.[10]

Bejelentkezési lekérések szerkesztés

Egy támadó elérheti, hogy az áldozat bejelentkezzen egy weboldalra a támadó adataival, ez az úgynevezett login CSRF. A login CSRF számos új támadást tesz lehetővé, például a támadó a későbbiekben bejelentkezhet a valódi adataival és megnézhet olyan privát információkat, mint például a felhasználóra mentett aktivitási történet.[11] A támadást a YouTube-on demonstrálták.[12]

Más megközelítések szerkesztés

Amíg a CSRF-et tipikusan mint egy statikus támadás írják le, a CSRF létrejöhet dinamikusan, egy cross-site scripting támadás payload-jaként, ahogy a Samy féreg demonstrálta, avagy létrejöhet töltődés közben, a weboldalon kívüli tartalom által szivárogtatott session információkkal és a célt egy támadó linkre irányíthatja. A CSRF tokeneket egy kliensnek többféle sebezhetőségen keresztül, de akár brute-force támadáson keresztül is küldhetnek,[13] amelyet egy támadó weboldalon renderelhetnek, akár több ezer sikertelen lekérés küldésével. A "Dynamic CSRF" (dinamikus CSRF) támadásosztály, továbbá a kliensalapú payload használata a session-specifikus hamisításhoz 2009-ben lett leírva Nathan Hamiel és Shawn Moyer által, a BlackHat Breifings-en.[14][15]

Megakadályozás szerkesztés

A különböző internethasználók, akik a különböző webböngészők változatlan verzióit használják, keveset tehetnek a CSRF támadások ellen. A weboldalakról való kijelentkezés és az "emlékezzen rám" opciók elkerülése csökkentheti a CSRF veszélyét, továbbá a külső képek kikerülése és a spamekben vagy nem megbízható forrású e-mailekben található linkek klikkelésének megakadályozása is segíthet.

A különböző böngészőkiegészítők, mint a RequestPolicy (Mozilla Firefox böngészőhöz) megakadályozhatják a CSRF-et egy alapértelmezett engedélyezés-tiltás szabállyal az oldalon-túli kérésekkel. Mindazonáltal ez számos weboldal normális működését is megakadályozhatja. A CsFire kiegészítő (szintúgy Firefox böngészőhöz) csökkentheti a CSRF hatását, kevesebb beavatkozással a böngészésbe, az oldalak közti kérésekből az autentikációs információk eltávolításával.

A weboldalaknak számos CSRF-ellenes intézkedése lehet:

  • Egy specifikus, kizárólagosan felhasznál-specifikus token kérése minden űrlapelküldésnél és linkben, ami miatt a támadó weboldala nem tudja a helyes tokent adni a CSRF inputoknál[6]
  • A klienstől való autentikációs adat kérése minden HTTP-lekérésben, amely biztonsági problémákat vethet fel (így például a pénzátutalás)
  • A session-sütik megmaradási idejének limitálása
  • A HTTP Referer fejrész és/vagy a HTTP Origin fejrész ellenőrzése[16]
  • Annak biztosítása, hogy nincs clientaccesspolicy.xml fájl, ami nemkívánt hozzáférést adhat a Silverlightnak[17]
  • Annak biztosítása, hogy nincs crossdomain.xml fájl, ami nemkívánt hozzáférést adhat a Flashnek[18]
  • Annak ellenőrzése, hogy a fejrész tartalmaz egy X-Requested-With fejrészt. Ezt a Ruby on Rails (a v2.0 előtt) és a Django (v1.2.5 előtt) tartalmazza. Ezen védelem bizonyítottan nem biztonságos[19] megfelelő böngészőpluginek és átirányítások alkalmazásával a támadó létrehozhat egyéni HTTP-fejrészeket, amely ezáltal engedélyezi a cross-site request forgery bekövetkezését.

Egy egyszerű és hatékony eljárás a CSRF megakadályozására egy CSRF filter használata, például az OWASP CSRFGuard-é. A filter elfogja a HTTP válaszokat, detektálja, hogy HTML-dokumentumok-e, és egy titkos tokent ad az űrlapokhoz, továbbá opcionálisan beilleszt szkripteket és AJAX függvényeket. A filter továbbá a lekéréseket is elfogja, annak ellenőrzésére, hogy jelen van-e a token.

Egy változat erre a JavaScripttel rendelkező felhasználók számára a sütik kétszeri elküldése. Ha egy autentikációs sütit a JavaScript olvas az elküldés előtt, a JavaScript szigorúbb (és jobb) crossdomain szabályai (same-origin policy) lépnek érvénybe. Ha a szerveren szükségesek lekérések, ahol az autentikációs sütit a POST lekérések body-jában vagy a veszélyes GET lekérések URL-jében tárolják, akkor a kérésnek megbízható domainról kell érkeznie, hiszen más domainek nem tudják a sütit beolvasni a megbízó domainben.

A HTTP Referer fejrész ellenőrzése, hogy a lekérés megbízható forrásból érkezik-e is egy gyakori módszer, hiszen nem növeli a memóriakövetleményeket. Mindazonáltal egy lekérés, mely egy Referer-t kiad, nem tekinthető autorizáltnak, hiszen a támadó a Referer-t "elnyomhatja" az FTP-n vagy HTTPS URL-eken keresztüli lekérésekkel. Ez a szigorú Referer problémákat okozhat olyan böngészőkben, amelyek nem adják ki a Referer fejrészt biztonsági okokból. Továbbá a Flash régi (9.0.18 előtti verziói) megengedik a támadó Flash fájlnak a HTTP Referer header létrehozását CRLF Injection használatával. Hasonló CLRF-befecskendezéses támadásokat használnak a kliensekben a "referer spoofing"-ra.

A hamisított bejelentkezési lekérések ellen a weboldalak szintén ezen CSRF-ellenes intézkedéseket használhatják, még akár mielőtt a felhasználó bejelentkezett volna.

A jelentékeny biztonság-szükséglettel rendelkező weboldalak, mint például a bankok a felhasználót például 15 perc után kiléptethetik.

A HTTP által meghatározott GET és POST használat felhasználása, amelyben a GET lekérések nem rendelkeznek permanens behatással jó gyakorlat, de nem akadályozza meg a CSRF-et. A támadók írhatnak JavaScriptet vagy ActionScriptet, amely láthatatlanul elküldi a támadást a céldomainre.[6]

A Cross-site scripting (XSS) sebezhetőségek (még más, azonos domainen futó alkalmazásoknál is) lehetővé teszik a támadóknak a CSRF-védelmek megkerülését.[20]

Jegyzetek szerkesztés

  1. ↑ a b Ristic, Ivan. Apache Security. O'Reilly Media, 280. o. (2005). ISBN 0-596-00724-8 
  2. ↑ Burns, Jesse: Cross Site Request Forgery: An Introduction To A Common Web Weakness. Information Security Partners, LLC, 2005. [2011. szeptember 11-i dátummal az eredetiből archiválva]. (Hozzáférés: 2011. december 12.)
  3. ↑ Christey, Steve and Martin, Robert A.: Vulnerability Type Distributions in CVE (version 1.1). MITRE Corporation, 2007. május 22. (Hozzáférés: 2008. június 7.)
  4. ↑ „Hacker Steals Data on 18M Auction Customers in South Korea”, DarkReader , 2008. február 1.. [2012. november 30-i dátummal az eredetiből archiválva] (Hozzáférés: 2012. április 13.) 
  5. ↑ List of incidents for which Attack Method is Cross Site Request Forgery (CSRF). Web Application Security Consortium, 2008. február 1. (Hozzáférés: 2008. július 4.)
  6. ↑ a b c Shiflett, Chris: Security Corner: Cross-Site Request Forgeries. php|architect (via shiflett.org), 2004. december 13. (Hozzáférés: 2008. július 3.)
  7. ↑ Nizamutdinov, Marsel: XSS & CSRF: Practical exploitation of post-authentication vulnerabilities in web applications, 2012. január 17.[halott link]
  8. ↑ US-CERT vulnerability list by severity metric. [2013. március 8-i dátummal az eredetiből archiválva]. (Hozzáférés: 2012. július 31.)
  9. ↑ cPanel Remote Root
  10. ↑ OpenCA CSRF
  11. ↑ Adam Barth, Collin Jackson, and John C. Mitchell, Robust Defenses for Cross-Site Request Forgery, Proceedings of the 15th ACM Conference on Computer and Communications Security, ACM 2007
  12. ↑ Jeremiah Grossman, Google YouTube crossdomain security flaw
  13. ↑ Inferno Security Blog Brute-forcing CSRF tokens Archiválva 2012. július 9-i dátummal a Wayback Machine-ben
  14. ↑ Weaponizing Web 2.0
  15. ↑ Dynamic CSRF. [2010. február 13-i dátummal az eredetiből archiválva]. (Hozzáférés: 2010. február 13.)
  16. ↑ Archivált másolat. [2012. május 28-i dátummal az eredetiből archiválva]. (Hozzáférés: 2012. július 31.)
  17. ↑ Client access policy file to allow cross-domain access by Silverlight controls
  18. ↑ Cross-domain policy file usage recommendations for Flash Player
  19. ↑ Django 1.2.5 release notes. Django. [2012. július 22-i dátummal az eredetiből archiválva]. (Hozzáférés: 2012. július 31.)
  20. ↑ "Article about CSRF and same-origin XSS". [2012. augusztus 14-i dátummal az eredetiből archiválva]. (Hozzáférés: 2012. július 31.)

Fordítás szerkesztés

Ez a szócikk részben vagy egészben a Cross-site request forgery című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További információk szerkesztés

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Cross-site_request_forgery&oldid=26910129”