Képzeld el, hogy valaki rávesz egy látogatót, hogy kattintson egy linkre, miközben be van jelentkezve a bankszámlájára. Ez a link egy rejtett űrlaphoz vezet, amely a látogató tudta nélkül kérést küld a banknak pénzátutalásról. A bank egy hitelesített felhasználótól érkező szabályos kérést lát, és végrehajtja. A támadó most pénzt mozgatott az áldozat számlájáról anélkül, hogy valaha ismerte volna a jelszavát.
Ez a CSRF (Cross-Site Request Forgery, azaz webhelyek közötti kéréshamisítás): olyan támadás, amelyben a támadó rávesz egy áldozatot, hogy tudtán kívül küldjön be egy űrlapot vagy kérést egy másik weboldalra, ahová az áldozat már be van jelentkezve.
Ezt fogod megtanulni: mik a CSRF-támadások, és hogyan működnek, miért olyan veszélyesek akkor is, ha más biztonsági intézkedések is vannak, hogyan akadályozzák meg őket a CSRF-tokenek, és hogyan vezess be védelmet az űrlapjaidon.
Mi az a CSRF?
A CSRF (kiejtése: „szí-szörf”) a Cross-Site Request Forgery rövidítése. Olyan támadás, amelyben a támadó kihasználja, hogy ha be vagy jelentkezve egy weboldalra, a böngésződ automatikusan megbízik a munkamenetedben, és minden kérésedhez csatolja azt az adott oldalra, még akkor is, ha a kérés egy másik weboldalról érkezik.
A támadás úgy működik, hogy a bejelentkezett látogatót rávesznek, hogy tudtán kívül küldjön be egy űrlapot egy olyan weboldalra, ahol fiókja van. A támadó nem látja az áldozat jelszavát. Nincs is rá szüksége. Csak az kell neki, hogy az áldozat már be legyen jelentkezve, aztán rávegye, hogy olyan kérést küldjön (például egy rejtett űrlap beküldésével), amely azt teszi, amit a támadó akar.
A CSRF más támadásoktól eltérően nem igényel hitelesítő adatok ellopását vagy titkosítás feltörését. Az áldozat weboldalba vetett bizalmát használja ki. Az áldozat már hitelesítve van, ezért a weboldal megbízik azokban a kérésekben, amelyek tőle érkeznek.
Hogyan működnek a CSRF-támadások
A CSRF-támadás három lépésben történik.
1. lépés: az áldozat be van jelentkezve az oldaladra
Valaki meglátogatja a weboldaladat, és bejelentkezik a fiókjába. A böngészőjében most aktív munkamenet-süti van, amely igazolja a hitelesítését. Ez a munkamenet aktív marad, amíg az oldalt használja.
2. lépés: a támadó rávesz egy rosszindulatú oldal meglátogatására
Amíg az áldozat még be van jelentkezve az oldaladra, meglátogat egy oldalt, amelyet a támadó irányít (talán egy közösségi médiából érkező link, egy félrevezető hirdetés, vagy egy szabályosnak tűnő weboldal). Azon az oldalon rejtett kód van, amely egy űrlapot küld vissza az oldaladra.
3. lépés: az űrlap automatikusan beküldődik az áldozat munkamenetével
A rejtett űrlap beküldődik a weboldaladra. Mivel az áldozat már be van jelentkezve, a böngészője automatikusan csatolja a munkamenet-sütijét a kéréshez. Az űrlapod szempontjából ez egy hitelesített felhasználó szabályos kérése. Az űrlap úgy dolgozza fel, mintha az áldozat szándékosan küldte volna be.
A támadó most olyat tett az oldaladon az áldozat fiókjával, hogy az áldozat nem tudott róla. Megváltoztathatta a jelszavát, pénzt utalhatott, frissíthette a profilját vagy adatot küldhetett be.
Miért működik ez akkor is, ha más biztonsági intézkedések is vannak
A CSRF-támadások több gyakori biztonsági funkciót megkerülnek:
A HTTPS nem állítja meg a CSRF-et. Az adat útközben titkosított, de a támadónak nem kell elfognia. Egyszerűen az áldozat böngészőjéből küldi a kérést, amelyben az áldozat böngészője már megbízik.
A jelszóvédelem nem állítja meg a CSRF-et. A támadónak soha nincs szüksége az áldozat jelszavára. Csak azt használja ki, hogy az áldozat már be van jelentkezve.
Az erős bejelentkezési rendszer nem állítja meg a CSRF-et. Még ha a hitelesítés tökéletes is, ha az áldozat be van jelentkezve, a támadás működik.
Ezért a CSRF-védelem külön réteg. Más biztonsági intézkedések nem előzik meg. Az űrlapokat kifejezetten úgy kell megtervezni, hogy ellenálljanak a CSRF-támadásoknak.
CSRF-tokenek: hogyan állítják meg a támadást
A megoldás a CSRF-token. Ez egy egyedi, kiszámíthatatlan karakterlánc, amelyet a szervered generál minden űrlaphoz. Így működik:
A szervered egyedi tokent hoz létre minden látogatónak
Amikor valaki betölt egy űrlapot tartalmazó oldalt, a szervered véletlenszerű tokent generál, és társítja az adott felhasználó munkamenetéhez. Ez a token minden alkalommal más, és egyedi az adott felhasználóra.
A token be van ágyazva az űrlapba
A token rejtett mezőként kerül az HTML-űrlapba. Amikor a látogató beküldi az űrlapot, a token vele utazik.
A szervered ellenőrzi a tokent a beküldés feldolgozása előtt
Amikor az űrlapot beküldik, a szervered ellenőrzi, hogy a beküldésben lévő token egyezik-e azzal, amelyet az adott felhasználó munkamenetéhez generáltál. Ha igen, az űrlap feldolgozódik. Ha nem (vagy ha nincs token), az űrlapot elutasítja.
A támadó rejtett űrlapja nem tartalmazhat érvényes tokent, mert a tokenek kiszámíthatatlanok, és minden munkamenethez egyediek. A másik domainen lévő támadó nem láthatja vagy találhatja ki a tokent. Így a támadása meghiúsul. A rejtett űrlap beküldődik, de a szervered elutasítja, mert a token nem egyezik.
Hogyan néz ki a CSRF-token a gyakorlatban
HTML-ben a CSRF-védett űrlap így néz ki:
<form method="POST" action="/submit-form"> <input type="hidden" name="csrf_token" value="a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"> <input type="email" name="email" placeholder="Az e-mail-címed"> <button type="submit">Küldés</button> </form>A `csrf_token` mező rejtett. A látogató nem látja, de az űrlapadatokkal együtt beküldődik. A szervered ellenőrzi, mielőtt feldolgozná az e-mailt vagy bármilyen más adatot.
CSRF-védelem különböző űrlaptípusokhoz
Hagyományos HTML-űrlapok
A szabványos HTML-űrlapoknak (azoknak, amelyek POST-tal küldenek adatot a szerveredre) kellenek CSRF-tokenek. Ide tartoznak a kapcsolati űrlapok, a bejelentkezési űrlapok, a jelszó-visszaállító űrlapok és minden űrlap, amely adatot módosít a szerveren.
AJAX és JavaScript űrlapok
A JavaScripttel egy API-végpontra küldött űrlapoknak is kell CSRF-védelem. A token beágyazható magába az űrlapba, tárolható sütiben, vagy kinyerhető egy meta tagből a kérés elküldése előtt.
Állapot nélküli API-kérések
Ha az API-d tokenalapú hitelesítést használ (például JWT-t), a CSRF-védelem másképp működik. A böngésző nem tud automatikusan JWT-tokent csatolni úgy, ahogyan a munkamenet-sütit, ezért a hagyományos CSRF kisebb fenyegetés. A bevált gyakorlat azonban továbbra is az, hogy extra védelemként tegyél be külön CSRF-tokent.
Egyéb védelmek, amelyek a CSRF-tokenekkel együtt működnek
A CSRF-tokenek az elsődleges védelem, de a legjobban más biztonsági gyakorlatokkal együtt működnek.
SameSite sütik
Amikor munkamenet-sütit állítasz be, hozzáadhatsz egy `SameSite` attribútumot, amely megmondja a böngészőnek, hogy ne csatolja a sütit, ha a kérés más domainről érkezik. Ez megakadályozza, hogy a támadó rejtett űrlapja egyáltalán használja az áldozat munkamenetét.
Referer fejléc ellenőrzése
A szervered ellenőrizheti a Referer fejlécet, hogy lássa, honnan jött a kérés. Ha egy űrlapbeküldés azt állítja, hogy a domainedről jön, de a Referer másik domaint mutat, valószínűleg támadás. (A Referer fejlécek azonban hamisíthatók, ezért ez nem teljes védelem.)
Dupla beküldéses süti minta
Ebben a megközelítésben a CSRF-token egy sütiben és egy űrlapmezőben is tárolódik. A szervered ellenőrzi, hogy egyeznek-e, mielőtt feldolgozna. Ez ritkább, mint a hagyományos tokenek, de jól működik állapot nélküli alkalmazásoknál.
Hogyan vezess be CSRF-védelmet
A megvalósítás részletei a technológiai stackedtől függnek, de a minta ugyanaz:
- Generálj egyedi tokent munkamenetenként. Amikor a felhasználó munkamenetet indít, vagy betölt egy űrlapoldalt, a háttérrendszered új tokent generál.
- Tárold a tokent a szerveroldalon. Mentsd az adott felhasználó munkamenetéhez társítva.
- Tedd be a tokent az űrlapba. Add hozzá rejtett mezőként az HTML-ben, vagy meta tagként, amelyet a JavaScript el tud olvasni.
- Ellenőrizd a beküldéskor. Bármilyen űrlapadat feldolgozása előtt nézd meg, hogy a beküldött token egyezik-e az adott munkamenethez tárolt tokennel.
- Generálj újat az érzékeny műveletek után. Miután a felhasználó megváltoztatja a jelszavát, vagy valami kritikusat tesz, generálj új tokent.
A legtöbb modern webes keretrendszer automatikusan kezeli a CSRF-token generálását és ellenőrzését. Ha keretrendszert használsz, a CSRF-védelem általában alapból be van kapcsolva. Csak arra figyelj, hogy véletlenül ne kapcsold ki.
Gyakori hibák, amelyek sebezhetővé teszik az űrlapokat
A CSRF-védelem kikapcsolása a kényelemért. Egyes fejlesztők kikapcsolják a CSRF-ellenőrzést, hogy megkönnyítsék az API tesztelését, vagy egyszerűsítsék a kódjukat. Ne tedd ezt. Valódi sebezhetőséget hoz létre.
Statikus token használata minden felhasználónak. A tokennek egyedinek kell lennie minden felhasználó munkamenetére. Az a token, amely mindenkinél ugyanaz (vagy minden felhasználónál minden napon ugyanaz), nem véd a CSRF ellen.
A tokenek nem újragenerálása. Ha ugyanazt a tokent hetekig használod, a támadónak több ideje van kihasználni. Generálj újra tokeneket rendszeresen, és mindig az érzékeny műveletek után.
Kizárólag a SameSite sütikre hagyatkozás. A SameSite hasznos, de nem elegendő. Használj CSRF-tokeneket elsődleges védelemként, a SameSite-ot pedig tartalékként.
Tokenek elfelejtése egyes űrlapokon. Ha egyes űrlapokat tokenekkel védesz, másokat nem, a támadók a védetlen űrlapokat fogják használni. Minden adatot módosító űrlapnak védelem kell.
Mit tesz a WEMASY a CSRF-védelemért
A WEMASY űrlapjai minden általad létrehozott űrlapon automatikusan tartalmaznak CSRF-token védelmet. Nem kell beállítanod vagy gondolkodnod rajta. Amikor a látogató beküld egy űrlapot, a WEMASY a beküldés tárolása előtt ellenőrzi a tokent. Ez a védelem be van építve, és alapból be van kapcsolva.
Tudj meg többet az űrlapbiztonsági lehetőségekről az árak oldalon.