Ebben a bejegyzésben körüljárjuk a Cross-site request forgery (CSRF) támadást, valamint megnézzük, hogy miként lehet ellene védekezni.
A probléma gyökere
Ahhoz, hogy a fejlesztők a weboldalak sebességét maximalizálni tudják, a forrásigényes tartalmakat másik domainekről (CDN) töltik be. Ilyen módon a weboldal vagy alkalmazás kapcsolatban van egy másikkal és kéréseket küldenek egymásnak, kommunikálnak. Ez nem jelent biztonsági kockázatot egészen addig, amíg ez bejelentkezés nélkül történik.
Ha egy felhasználó be van jelentkezve egy alkalmazásba, akkor a böngésző a kérés mellé elküldi a munkamenethez tartozó cookie-kat is, ezt használják ki a támadók, hogy kéréseket hamisítsanak.
A következő példa egyszerűen szemlélteti a problémát. A webes alkalmazásban ha meg akarjuk változtatni az e-mail címünket, küldünk egy GET kérést a szerver felé, ami így néz ki:
https://example.com/email/[email protected]
A szerver megkapja a kérést a cookie-val együtt és végrehajtja azt. A gond ott kezdődik, hogy a támadó is ismeri ezt a kérést és rávesz minket, hogy kattintsunk rá az általa módosított linkre, ahova a saját e-mail címét írja:
https://example.com/email/[email protected]
Az áldozat rákattint a linkre (például egy e-mailben) és mivel be van jelentkezve az alkalmazásba, a böngésző elküldi a cookie-t. A szerver ezt is egy valid kérésnek véli és végrehajtja azt.
Egy ilyen e-mail cím változtatás után a támadó jellemzően egy jelszó visszaállítást indít és át is veszi az irányítást az alkalmazás felett, kizárva a felhasználót.
Természetesen a való életben nem ennyire könnyű egy ilyen támadás, hiszen a modern alkalmazások POST kérések segítségével végzik a fontos műveleteket. Ilyen esetekben HTML oldalt készít a támadó, ami segítségével tőrbe tudja csalni az áldozatát.
A CSRF támadásokról és Payload készítésről részletesen a WEBES ETIKUS HACKER tanfolyamon tanulhatsz.
Hogyan védekezhetünk?
A Cross-site request forgery elleni védekezés nem egyszerű feladat, mert az egész alkalmazást érintő változásokat kell implementálni. Minden olyan interfészt biztosítani kell, ami módosításokat hajt végre.
A leggyakoribb egy úgynevezett (CSRF) token, amit az alkalmazás minden kérés mellé elküld és szerver oldalon validál. Ha ez a token kellően random, tehát a támadó nem tudja kitalálni vagy megjósolni, akkor véd a CSRF támadásokkal szemben.
Másik megoldás az úgynevezett SameSite Cookie, ami azt a célt szolgálja, hogy meg tudjuk adni milyen esetekben csatolja a Session Cookie-t a kérések mellé a böngésző.
Részletesen a SameSite Cookie-ról: https://web.dev/samesite-cookies-explained/