Hatás
A Cross-Site Request Forgery (CSRF) segítségével a támadó ráveheti az áldozat böngészőjét, hogy nem kívánt műveleteket hajtson végre egy másik webhelyen, ahol az áldozat jelenleg hitelesítve van. Mivel a böngészők automatikusan beillesztik a környezeti hitelesítési adatokat, például a cookie-kat a kérésekbe, a támadó a felhasználó tudta nélkül hamisíthat állapotváltoztató műveleteket – például jelszavak megváltoztatását, adatok törlését vagy tranzakciók kezdeményezését.
Kiváltó ok
A CSRF alapvető oka a webböngésző alapértelmezett viselkedése, amikor egy domainhez tartozó cookie-kat küld, amikor egy kérés érkezik az adott tartományba, függetlenül a kérés eredetétől. [S1]. Konkrét ellenőrzés nélkül, hogy egy kérést szándékosan indítottak el az alkalmazás saját felhasználói felületéről, a szerver nem tud különbséget tenni a jogos felhasználói művelet és a hamisított között.
Django CSRF védelmi mechanizmusok
A Django beépített védelmi rendszert biztosít ezeknek a kockázatoknak a mérséklésére a köztes szoftverek és a sablonok integrációján keresztül. [S2].
Köztes szoftver aktiválása
A django.middleware.csrf.CsrfViewMiddleware felelős a CSRF védelemért, és általában alapértelmezés szerint engedélyezve van. A CSRF-támadásokat feltételező nézeti köztes szoftverek előtt kell elhelyezni. [S2].
Sablon megvalósítása
Minden belső POST űrlap esetén a fejlesztőknek fel kell tüntetniük a {% csrf_token %} címkét a <form> [S2] elemen belül. Ez biztosítja, hogy egy egyedi, titkos jogkivonat szerepeljen a kérésben, amelyet a kiszolgáló a felhasználó munkamenetéhez képest érvényesít.
Token szivárgási kockázatok
Fontos megvalósítási részlet, hogy a {% csrf_token %} soha nem szerepelhet a [S2] külső URL-eket célzó űrlapokon. Ezzel kiszivárogtatná a titkos CSRF-jogkivonatot egy harmadik félhez, ami veszélyeztetheti a felhasználó munkamenet-biztonságát. [S2].
Böngésző szintű védelem: SameSite cookie-k
A modern böngészők bevezették a SameSite attribútumot a Set-Cookie fejléchez, hogy mélyreható védelmet biztosítsanak a [S1].
- Szigorú: A cookie csak belső kontextusban kerül elküldésre, ami azt jelenti, hogy az URL-sávban lévő webhely megegyezik a cookie [S1] domainjével.
- Lax: A cookie nem a webhelyek közötti alkérelmekre (például képekre vagy keretekre) kerül elküldésre, hanem akkor kerül elküldésre, amikor a felhasználó a kiindulási webhelyre navigál, például egy szabványos hivatkozás követésével [S1].
Hogyan teszteli a FixVibe
A FixVibe immár tartalmazza a CSRF-védelmet is, mint kapuzott aktív ellenőrzést. A tartomány ellenőrzése után a active.csrf-protection megvizsgálja a felfedezett állapotváltoztató űrlapokat, ellenőrzi a CSRF-token alakú bemeneteket és a SameSite cookie-jeleket, majd megkísérli az alacsony hatású hamisított eredetű beküldést, és csak akkor jelent, ha a szerver elfogadja azt. A cookie-ellenőrzések a gyenge SameSite attribútumokat is megjelölik, amelyek csökkentik a CSRF védelmét.