Cross-Site Request Forgery (CSRF, XSRF) sérülékenység javítása, megelőzése

Mi az a Cross-Site Request Forgery (CSRF, XSRF) sérülékenység, támadás?

Cross-Site Request Forgery (CSRF, XSRF) sérülékenység kihasználása során a kibertámadó a célpont felhasználó egyik aktív bejelentkezési munkamenetét használja fel arra, hogy a sérülékeny webalkalmazás valamilyen funkcióját felparaméterezze és aktiválja, méghozzá a célpont felhasználó böngészőjében és annak nevében.

Ezt jellemzően valamilyen támadó kódot (a sérülékeny webalkalmazás valamelyik HTTP GET vagy POST kérését, adatküldését) tartalmazó weboldal létrehozásával és célpontnak való elküldésével és megnyittatásával éri el.

Például: A Cross-Site Request Forgery (CSRF, XSRF) módszerrel támadható webes szolgáltatás nemcsak azokat a feladatokat végzi el, amiket a bejelentkezett felhasználó vagy adminisztrátor a hivatalos felületen ad ki a kiszolgálónak, hanem azokat is, amiket egyéb támadói forrásból, például egy hamis webes űrlaptól, URL-betöltéstől vagy dinamikus kódtól kap. Ide tartozik a szenzitív információk szivárogtatása is.

Mi a Cross-Site Request Forgery (CSRF, XSRF) sérülékenység kockázata?

Ha a webes szolgáltatás nem kezeli és korlátozza megfelelően a felé irányuló kéréseket, akkor olyan kódok futhatnak le az áldozat(ok) böngészőjében, amik lopásra, adathalászatra, dezinformáció terjesztésére és akár szerver- és kliensoldali manipulációra is használhatók.

Hogyan javítható és előzhető meg a Cross-Site Request Forgery (CSRF, XSRF) sérülékenység?

• CSRF-token generálása, kiszolgálókérésben való elhelyezése, kiszolgálóoldali ellenőrzése
• hash (munkamenet-azonosító, funkció neve, kiszolgálóoldali kulcs) minden űrlap számára és kiszolgálóoldali validálása
• Munkamenet-azonosítók kiszolgálóoldali generálása, kliensoldali integrációja, és kiszolgálóoldali ellenőrzése
• SameSite=Strict vagy SameSite=Lax sütiparaméter kombinálása a CSRF-tokennel
• A beviteli adatok kiszolgálóoldali ellenőrzése
• HTTP Referer ellenőrzése
• Cookie session azonosító

Miért nem elég a SameSite sütiparaméter használata a Cross-Site Request Forgery (CSRF, XSRF) sérülékenység javítására?

A SameSite=Strict értékű sütiparaméterrel ellátott sütiket a böngésző csak akkor küldi a kiszolgálónak, ha a kiszolgálókérés a sütit készítő weboldalról érkezik, tehát egy külső linkről való „érkezés” esetén a munkamenet-süti már nem kerül elküldésre, tehát jelentősen romlik a felhasználói élmény.

A SameSite=Lax értékű sütiparaméterrel ellátott sütik esetében a böngésző már megengedőbb, de ezeket is kizárólag a HTTP GET kiszolgálókérésekben küldi el a kiszolgálónak és csak akkor, ha az közvetlen felhasználói kattintási interakció eredménye.

Mivel számos CSRF-támadás során HTTP POST-beküldéseket alkalmaznak, a SameSite bizonyos szintű védelmet képes nyújtani a Cross-Site Request Forgery-vel szemben, de tekintettel arra, hogy vannak esetek amikor a kiszolgáló HTTP GET-kérések formájában (is) képes jelentősebb hatásokat eredményező funkciókat paraméterezetten elindítani, a SameSite használata önmagában kevésnek tekinthető a Cross-Site Request Forgery (CSRF, XSRF) sérülékenység javítására.

Hogyan ellenőrizhető a Cross-Site Request Forgery (CSRF, XSRF) sérülékenység jelenléte?

• Sérülékenységvizsgálat szolgáltatás igénylésével
• Manuális vizsgálatokkal, amely során speciális HTML-lapokkal próbáljuk az érintett funkciókat működésbe hozni

Kapcsolódó weboldalak

• Wikipedia
• owasp.org
• OWASP CSRFguard

Kapcsolódó szolgáltatások és termékek