Súlyos sebezhetőségre figyelmeztet a Fortinet Orosz állami hackerek forráskódokat lophattak el a Microsofttól Mi az a Ransomware-as-a-Service? 110 milliós bírságot kapott a KRÉTA meghekkelt fejlesztője Szoftverengedélyezési folyamat – Kiberbiztonsági ellenőrzőlista Letartóztatták a LockBit néhány tagját, kiadtak egy dekriptáló szoftvert Broken Object Level Authorization sérülékenység javítása, megelőzése A titkosított Signal üzenetküldő bevezetet a felhasználóneveket Információbiztonság vs. kiberbiztonság Felhőalapú kiberbiztonsági tanácsadás és audit Kiberbiztonsági partnerprogram CVSS: Common Vulnerability Scoring System Sérülékenységvizsgálat, penetrációs teszt és red teaming jellemzői Session Hijacking sérülékenység javítása, megelőzése Kövessen Minket LinkedInen is!

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?

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?

Kapcsolódó weboldalak

Sérülékenységvizsgálat és penetrációs teszt szolgáltatás
Árajánlat