A csrf-támadás elleni védelem módszerei habrahabr
Mi a CSRF támadás?
Megismerheti a klasszikus erőforrásokkal kapcsolatos CSRF-támadás ötletét:
Kivonat a SO-re adott válaszból:
CSRF oka abban a tényben rejlik, hogy a böngésző nem értik, hogyan kell felismerni, hogy a hatás egyértelműen a felhasználó által (mint például egy gomb megnyomásával a formában, vagy kövesse a link), vagy egy felhasználó akaratlanul végrehajtani ezt a műveletet (például amikor meglátogatja bad.com. Resource egy kérelmet küldött a good.com/some_action címre, míg a felhasználó már bejelentkezett a good.com-ba).
Hogyan lehet megvédeni tőle?
Hatékony és általánosan elfogadott módszer a CSRF-támadás elleni védelemre. A token egy olyan véletlen bájtkötegre utal, amelyet a kiszolgáló küld az ügyfélnek, és az ügyfél visszatér a kiszolgálóhoz.
A védelem csökkenti a kiszolgáló által generált token és a felhasználó által küldött jelző ellenőrzését.
És mit védekezni?
Ha webszolgáltatását az RFC7231 szerint írja. majd GET módszerek. HEAD. Az OPTIONS és a TRACE biztonságosak: csak tájékoztató jellegűek, és nem változtathatják meg a szerver állapotát.
Ezért meg kell védeni a nem biztonságos módszereket, amelyek a következők: POST. PUT. DELETE. Patch.
A token követelményei:
- Egyedi jelző minden egyes művelethez # 13;
- Cselekedni egyszer # 13;
- Olyan méretű, amely ellenáll a kiválasztásnak # 13;
- A kriptográfiailag stabil pszeudo-véletlenszám-generátor által generált # 13;
- Korlátozott élettartammal rendelkezik # 13;
Az első MeetUp'e PDUG Timur Yunusov (a 13. banki biztonsági osztály vezetője, a Positive Technologies rendszerek) elmondta. miért pontosan ezeket a követelményeket szabják meg a CSRF-Token-nek és mi fenyeget, hogy elhanyagolja őket.
A webszolgáltatás és a környezet követelményei:
XSS sérülékenységek hiánya
Ezért az XSS sebezhetőségek az aktuális token megszerzésére használhatók.
Nincs kártékony program az ügyfélgépen
Ha egy támadó képes az ügyfélgépen futtatni a szoftvert, akkor a böngészőben elérhető bármilyen adat.
A védelem módszerei
Három módszer van a tokenek használatára a webszolgáltatások CSRF támadások elleni védelme érdekében:
Tokens szinkronizátor
Egyszerű megközelítés, amelyet mindenhol használnak. Szükség van egy token tárolására a szerver oldalon.
A munkamenet kezdetén egy kiszolgálói oldalon egy token jön létre.
A token a munkamenet adattárolóba kerül (azaz a kiszolgálói oldalon tárolja a későbbi ellenőrzéshez)
Egy kérésre (amely megkezdte a munkamenetet) válaszul egy tokent visszaküld az ügyfélnek.
Ha a renderelés a szerveren történik. akkor a token visszatérhet a HTML belsejébe, például egy űrlapmezõbe vagy belsejében tag.
Abban az esetben, ha a válasz visszaküldik a JS alkalmazáshoz. a token átadható a fejlécnek (gyakran az X-CSRF-Token használatával)
A későbbi kérelmek esetében az ügyfélnek át kell adnia a tokenet a kiszolgálónak ellenőrzésre.
Amikor a tartalom a szerver által renderelt, a tokent általában visszaadják a POST űrlapon belül.
A JS alkalmazások általában XEN kéréseket küldnek fejléccel (X-CSRF-Token), amely egy tokenet tartalmaz.
Ha egy kérést egy nem biztonságos módszerrel (POST.PUT.DELETE.PATCH) fogadunk, akkor a kiszolgálónak ellenőriznie kell a token személyazonosságát a munkamenet adataiból és az ügyfél által küldött jelnek.
Ha mindkét tokens megegyezik, akkor a kérésnek nem volt alávetése a CSRF-Attacknak, különben - be kell jelentkeznünk az eseményre, és el kell utasítanunk a kérést.
A kimeneten:
A CSRF védelme jó szinten
A token csak akkor frissül, ha a munkamenet újraépül. és ez akkor történik, amikor a munkamenet lejár
Egy munkamenet időtartama alatt minden műveletet ellenőrizni fognak egy tokenel.
Ha egy token szivárgás bekövetkezik, a támadó képes bármilyen CSRF támadásra és hosszú időre. És ez nem jó.
A böngészőben a többfunkciós eszköz támogatása ingyenes.
A lekérdezés végrehajtása után a tokent nem érvénytelenítik, ami lehetővé teszi a fejlesztő számára, hogy ne aggódjon a token szinkronizálásához a böngésző különböző lapjaiban, mivel a token mindig egy.
Double Küldje el a cookie-t
Ez a megközelítés nem igényli az adatok tárolását a szerver oldalon, ami azt jelenti, hogy hontalan. Használt, ha gyorsan és kvalitatív módon szeretné tudni vízszintesen a webszolgáltatását. # 13; Az ötlet az, hogy a jelzőt az ügyfélnek kétféle módon adjuk: a cookie-kban és az egyik válaszparaméterben (fejléc vagy belső HTML).
Az ügyféltől kapott kérelem esetén a kiszolgáló oldalon egy tokent hoz létre. Válaszként a token visszatér a cookie-ba (például X-CSRF-Token) és az egyik válaszparaméterben (a fejlécben vagy a HTML belsejében).
A későbbi kérelmekben az ügyfélnek mind a korábban vett tokeneket kell biztosítania. Az egyik olyan, mint egy cookie, a másik egy fejléc. akár a POST formanyomtatványon belül.
Ha egy kérelmet egy nem biztonságos módszerrel (POST.PUT.DELETE.PATCH) fogadunk, akkor a kiszolgálónak ellenőriznie kell, hogy a tokens azonosítója a cookie-ból és az ügyfél által explicit módon küldött tokennek.
Ha mindkét tokens megegyezik, akkor a kérésnek nem volt alávetése a CSRF-Attacknak, különben - be kell jelentkeznünk az eseményre, és el kell utasítanunk a kérést.
A kimeneten:
Hontalan CSRF-védelem.
Így ha a szolgáltatás harmadik szintű tartományban érhető el, és a támadó képes arra, hogy egy erőforrást regisztráljon a második szintű domainre, akkor explicit módon állítsa be a cookie-t a domainjén.
# 13;Titkosított token
Csakúgy, mint a Double Submit, ez egy hontalan megközelítés. A legfontosabb dolog az, hogy ha bármilyen adatot bizalmas algoritmussal titkosít, és átküldi az ügyfélnek, az ügyfél nem tudja meggyőzni őket anélkül, hogy tudná a kulcsot. Ez a megközelítés nem igényel cookie-kat. A token az ügyfélnek csak válaszparaméterekben kerül elküldésre.
Ebben a megközelítésben a token a kulccsal titkosított tények. A minimálisan szükséges tények a token generációs idő felhasználói azonosítója és időbélyege. A kulcs nem ismert az ügyfél számára.
Az ügyféltől kapott kérelem esetén a kiszolgáló oldalon egy tokent hoz létre.
A token létrehozása a token érvényesítéséhez szükséges tények titkosítása a jövőben.
A minimálisan szükséges adatok a felhasználói azonosító és az időbélyeg. Válaszként a token a válaszparaméterek valamelyikében kerül visszaadásra (a fejlécben vagy a HTML belsejében).
A későbbi kérelmekben az ügyfélnek meg kell adnia a korábban kapott tokent.
Ha egy kérelmet egy nem biztonságos módszerrel (POST.PUT.DELETE.PATCH) fogadunk, akkor a kiszolgálónak meg kell erősítenie az ügyféltől kapott tokent.
A token érvényre juttatása visszafejteni, és a dekódolás után kapott tényeket összehasonlítani a valós értékekkel. (Időzített ellenőrzés szükséges a token élettartamának korlátozásához)
Ha a visszafejtés sikertelen, vagy a tények nem egyeznek meg, úgy tekintjük, hogy a kérelmet CSRF-Attacknak vetették alá.
A kimeneten:
A megvalósításról
Minden kérelemhez hozzon létre egy új jelzőt, függetlenül attól, hogy milyen HTTP-módszer és milyen célra készült ez a kérés.
Így kapunk egy tokenet, amely folyamatosan változik.
Természetesen felmerül a többfunkciós munka megszervezésének kérdése.
A fülek közötti szinkronizálás a localStorage és a StorageEvent segítségével valósítható meg
Korlátozzuk a sütemény élettartamát, amely a tokenet ésszerű értéket tartalmazza. Például 30 perc.
A cookie-t nem lehet elérni a JS-től (HTTPOnly = true)
Használja a TLS-ot a MITM megakadályozására
Ebben az esetben a cookie-kat csak HTTPS-n keresztül küldjük el (Secure = true)
A token mérete nem kevesebb, mint 32 bájt.
Egy tokenet generálunk kriptográfiailag stabil pszeudo-véletlenszám-generátorral.
Ehhez a rendszerfunkciókat használhatja:
Mi mást kell tudnia?
A tokenek kötelező védelmet nyújtanak a CSRF ellen.
Ellenőrizze, de ne kizárólag az X-Requested-With -ra hivatkozzon: XMLHttpRequest
Ellenőrizze, de ne csak a fejlécekre támaszkodjon: Host. Eredeti. referer
Ne adja át a tokeneket az URL-ben
Most a "Same-Site" attribútum specifikációjában dolgozunk a cookie-kban (a legfrissebb változat a cikk írásakor).
Az ilyen attribútum lehetővé teszi a fejlesztők számára, hogy kifejezetten jelezzék, hogy a cookie-t nem kell továbbítani, ha a kérés olyan webhelyről származik, amely nem a cookie telepítésének helye. Ezért lehetőségünk nyílik arra, hogy a források védelmét a CSRF-től megvédjük további eszközök használata nélkül.
A Chrome már támogatja ezt a funkciót.
További információ arról, hogy mi és miért van elérhető a Stack Exchange-en.