6.13. „Átverés – oldalakon keresztüli kérelem hamisítás” (Spoofing - Cross-Site Request Forgery (CSRF))

6.13.1. Áttekintés

A „CSRF” egy olyan támadás, ami arra kényszeríti a felhasználót, hogy olyan tevékenységet végezzen egy webes alkalmazásban, amibe éppen be van jelentkezve, amit nem állna szándékában megtenni. Egy kis „szocializációs mérnökösködéssel” (például hivatkozás küldése e-mailen vagy chat-en keresztül) a támadó arra kényszeríti a felhasználót, hogy olyan cselekedeteket hajtson végre, amiket a behatoló szeretne. Egy mezei felhasználó esetében egy sikeres CSRF támadás veszélybe sodorhatja a felhasználó adatait és tevékenységét. Ha a támadással megcélzott azonosító egy adminisztrátorhoz tartozik, akkor egy ilyen behatolás az egész webes alkalmazás biztonságát veszélyezteti.

6.13.2. Vonatkozó biztonsági intézkedések

6.13.2.1. Hogyan nézzünk át egy kódot CSRF sebezhetőséget keresve?

A OWASP Code Review Guide cikkben olvashatunk arról, hogy hogyan nézzünk át egy kódot CSRF sebezhetőség reményében (Reviewing code for CSRF).

6.13.2.2. Hogyan teszteljük a CSRF sebezhetőséget?

A OWASP Testing Guide cikkben olvashatunk arról, hogy hogyan teszteljük a CSRF sebezhetőséget (Test for CSRF).

6.13.2.3. Hogyan előzzük meg a CSRF sebezhetőséget?

A OWASP CSRF Prevention Cheat Sheet dokumentumban olvashatunk a sebezhetőség megelőzéséről.

Halgassuk meg a következő felvételt: OWASP Top Ten CSRF Podcast.

Egy kiváló írás John Melton tollából arról, hogy hogyan használjuk az OWASP ESAPI beépített anti-CSRF funkcióját: excellent blog post

6.13.2.4. Leírás

Az „oldalakon keresztüli kérelem hamisítás” (CSRF) egy olyan támadás, ami trükkös módon ráveszi az áldozatot, hogy olyan weboldalt nyisson meg, ami káros kérelmet tartalmaz. Ez olyan értelemben káros, hogy örökli az áldozat személyazonosságát és privilégiumait és ezekkel felszerelve az áldozat nevében nem kívánt tevékenységet végez, mint például megváltoztatja az e-mail címet, a lakáscímet, a különféle jelszavakat vagy éppen vásárol valamit. A CSRF támadások általában olyan funkciókat céloznak, amelyek valamilyen állapotváltozást idéznek elő a szerveren, de ezzel egy időben kényes információkat is megszerez.

A legtöbb oldalon a böngészők automatikusan tárolják a legtöbb ilyesfajta kérelmet, ami bármilyen, a weboldalhoz tartozó igazoló adatot tartalmaz, mint például a felhasználó session cookie-ját, alapvető bejelentkezési adatait, IP címét, Windows domain adatait, stb. Így ha a felhasználó éppen be van jelentkezve az oldalra, akkor az oldalnak esélye sincs a hamis kérelmet megkülönböztetni a a valódi felhasználói kérelemtől.

Ez úton a támadó úgy intézheti, hogy az áldozat olyasmit csináljon, amit nem akart volna, például kijelentkezhet, vásárolhat valamit, hozzáférési információkat változtathat meg, hozzáférési információkat szerezhet vissza vagy bármi egyéb, a sérülékeny weboldal által kínált funkciókat hajthat végre.

Néha lehetőség van arra, hogy a CSRF támadást magán a sérülékeny weboldalon tároljuk. Az ilyen sebezhetőségeket Tárolt CSRF hibának (Stored CSRF flaw) nevezzük. Ezt egyszerűen el lehet érni úgy, hogy egy IMG vagy IFRAME tag-et tárolunk egy olyan mezőben, ami elfogadja a HTML-t, de használhatunk jóval komplexebb kereszt-oldali szkriptelő támadást is. Ha a támadás képes tárolni egy CSRF támadást az oldalon, akkor a behatolás súlyossága megnő. Valójában nagyobb annak a valószínűsége, hogy az áldozat a támadást tartalmazó lapot nézi, mint egy másik, véletlenszerűen kiválasztott lapot az interneten. A valószínűség azért is nő, mert az áldozat már biztosan be van jelentkezve az oldalra.

Szinonímák: a CSRF támadások sok más néven is ismerik, mint például: XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery vagy  Hostile Linking. A Microsoft „Egykattintásos” támadásként (One-Click attack) hivatkozik erre a a fajta támadásra a fenyegetlés modellező folyamatában és sok más helyen az online dokumentációkban.

6.13.2.5. Megelőzési módszerek, amik NEM MŰKÖDNEK

Titkos cookie használata

Emlékezzünk arra, hogy minden cookie – még a titkosak is – elküldésre kerülnek minden kérelemmel. Minden azonosító token elküldésre kerül attól függetlenül, hogy a felhasználót csalással vették-e rá a kérelem elküldésére. Sőt, a session azonosítókat egyszerűen arra használja az alkalmazás tárolója, hogy összekapcsolja kérelmet egy bizonyos session objektummal. A session azonosító nem ellenőrzi, hogy a felhasználónak szándékában állt-e elküldeni a kérelmet.

Csak utólagos kérelmeket (POST request) fogadunk el

Az alkalmazásokat úgy is fel lehet építeni, hogy csak utólagos kérelmeket (POST request) fogadjanak el az üzleti logika alkalmazása végett. A tévhit az, hogy mivel a támadó nem tud káros hivatkozást összerakni, így a CSRF támadás nem kivitelezhető. Sajnos ez a logika nem helytálló. Számos olyan módszer van, amivel a támadó trükkös módon ráveheti az áldozatot, hogy elküldjön egy hamisított utólagos kérelmet, például egy egyszerű űrlap formájában, ami a behatoló oldalán van tárolva és rejtett értékeket tartalmaz. Ezt az űrlapot aztán a JavaScript könnyen aktiválhatja, de megteheti ezt az áldozat is, aki azt hiszi, hogy az űrlap valami mást fog csinálni.

6.13.2.6. PÉLDÁK

6.13.2.6.1. Hogyan működik a támadás?

Számos módja van annak, hogy trükkel rávegyük a felhasználót, hogy töltsön be vagy küldjön információt egy webes alkalmazásból/ba. A támadás kivitelezése céljából először azt kell átlátnunk, hogyan hozzunk létre olyan káros kérelmet, amit az áldozat végre fog hajtani. Vegyük szemügyre a következő példát: Aliz 100 dollárt szeretne utalni Robinak a bank.com oldalon keresztül. Az Aliz által generált kérelem nagyjából a következőképpen fog kinézni:

   POST http://bank.com/transfer.do HTTP/1.1
   ...
   ...
   ...
   Content-Length: 19;
   
   acct=BOB&amount=100
            

Mária azonban észreveszi, hogy ugyanaz a webes alkalmazás, a következő URL paraméterekkel hajtja végre ugyanazt az átutalást:

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

Mária úgy dönt, hogy kihasználja a webes alkalmazás eme gyenge pontját és Aliz lesz az áldozata. Először is Mária megszerkeszti a következő URL-t, ami át fog utalni 100000 dollárt Aliz számlájáról az övére:

http://bank.com/transfer.do?acct=MARIA&amount=100000

Most hogy a káros kérelme elkészült, Máriának trükkel rá kell vennie Alizt, hogy elküldje azt. A legalapvetőbb módja ennek az, hogy küld Aliznak egy HTML e-mailt, ami a következőket tartalmazza:

<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>

Feltéve, hogy Aliz be van jelentkezve az alkalmazásba, mikor rákattint a hivatkozásra, a 100000 dollár átvitele Aliz számlájáról Mária számlájára végbe fog menni. Azonban Mária azt is tudja, hogy ha Aliz rákattint a hivatkozásra, akkor észre fogja venni, hogy valamiféle tranzakció történt. Ezért Mária úgy dönt, hogy egy 0 bájtos képbe rejti a támadást:

<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0">

Ha ezt a kép tag-et beleteszi az email-be, akkor Aliz csak azt fogja látni, hogy egy kis doboz jelenik meg, mintha a böngésző nem tudta volna feldolgozni a képet. Azonban a böngésző ETTŐL FÜGGETLENÜL elküldi a kérelmet a bank.com oldalnak anélkül, hogy a tranzakciónak bármilyen látható jele lett volna.