CSRF a mobilfejlesztésben: lényeg, támadástípusok és védelmi módszerek

Mi az a CSRF-támadás?

A CSRF (Cross-Site Request Forgery) egy olyan támadás, amelyben a támadó hamis kérést hoz létre, és arra kényszeríti az áldozat böngészőjét, hogy azt elküldje a célszerverre. A szerver végrehajtja a kérést, mert megkapja a felhasználó aktuális munkamenetének érvényes cookie-hitelesítő adatait. A támadás azért lehetséges, mert a böngésző automatikusan hozzáadja a sütiket minden, a céltartományra irányuló kéréshez, függetlenül attól, hogy melyik oldalról küldték a kérést. Lehet, hogy a felhasználó nem is látta a támadó oldalát — elég egy rejtett <img>, <form> vagy <iframe> betöltése rosszindulatú URL-lel. A CSRF nem lop adatokat közvetlenül — a támadás műveleteket hajt végre az áldozat nevében (állapotváltoztató műveletek), mint pénzátutalás, jelszóváltoztatás vagy fiók törlése.

Mely műveletek a legsérülékenyebbek?

A CSRF-támadások kizárólag az állapotot módosító műveletekre irányulnak — GET-kérések mellékhatásokkal, POST, PUT és DELETE. Például egy e-mail cím módosítására irányuló kérés a személyes fiókban: ha a szerver elfogadja a kérést a forrás ellenőrzése nélkül, a támadó behelyettesítheti a saját e-mail címét és elindíthatja a jelszó-visszaállítást. A támadás különösen veszélyes a banki rendszerek, adminisztrációs panelek és közösségi hálózatok számára, ahol egyetlen művelet súlyos következményekkel jár. A cookie-kat hitelesítésre használó mobilalkalmazások API-i szintén ki vannak téve a CSRF-nek, ha nem alkalmaznak további ellenőrzéseket.

Ki van veszélyben?

Bármely webalkalmazás és API, ahol a hitelesítés sütin alapul, és a szerver nem ellenőrzi a kérés forrását, támadásnak van kéteve. A WebView-t használó mobilalkalmazások a webes űrlapokon keresztüli engedélyezéshez szintén sérülékenyek: a böngésző összetevő automatikusan elküldi a sütiket, és a támadó háttérbetöltéssel rosszindulatú kérést injektálhat. A HackerOne (2025) szerint az összes webalkalmazásokkal kapcsolatos sérülékenységi jelentés körülbelül 12%-a a CSRF elleni védelem hiányához kapcsolódik.

Mitől veszélyes a CSRF?

A CSRF fő jellemzője az áldozat számára való láthatatlanság. Lehet, hogy a felhasználó nem is gyanítja, hogy támadás történt: a hamis kérés a háttérben fut le, és az alkalmazás felülete nem mutat betörésre utaló jeleket. A CSRF észlelésének egyetlen módja a szervernaplók figyelése vagy a fiókban bekövetkező hirtelen változások. Ezenkívül a CSRF könnyen kombinálható más sérülékenységekkel, mint az XSS vagy a nyitott átirányítások, ami többszörösére növeli a kárt.

Hogyan működik a CSRF-támadás?

A CSRF-támadás három kötelező feltételből áll: az áldozat hitelesítve van a céloldalon, a szerver cookie-hitelesítést használ, és a támadó kérése a művelet URL-jére irányul. A támadó létrehoz egy HTML-oldalt egy űrlappal, szkripttel vagy képpel, amelynek src attribútuma a cél URL-re mutat. Az áldozat böngészője betölti ezt az oldalt, és automatikusan elküldi a kérést a szerverre az aktuális munkamenet sütijével együtt. A szerver érvényes sütiket kap, nem ellenőrzi a kérés forrását, és végrehajtja a műveletet.

<!-- Példa rejtett űrlapos CSRF-támadásra -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

Az oldal betöltése után a szkript azonnal elküldi az űrlapot. A böngésző hozzáfűzi a felhasználó munkamenet-sütijét a bank.example.com címre küldött POST-kéréshez. A bank szervere ellenőrzi a sütit, megerősíti, hogy a felhasználó hitelesítve van, és végrehajtja az átutalást a támadó számlájára. Az áldozat üres vagy jogos oldalt lát, a pénz pedig már leírásra került.

A böngésző szerepe a CSRF-ben

A HTTP protokoll fő jellemzője — a kérés beépített forrásellenőrzésének hiánya. A böngésző hozzáadja a sütit a kéréshez, ha a kérés tartománya megegyezik a süti tartományával. A támadónak nem kell ismernie a süti tartalmát — a böngésző ezt automatikusan megteszi. Az azonos eredetű szabály nem véd a CSRF ellen, mert a támadás a szerverre irányul, nem a válasz olvasására. Az olyan mechanizmusok, mint a CORS, szintén erőtlenek: a CSRF-kérések általában nem igénylik a válasz olvasását a károkozáshoz.

A CSRF-támadások fő típusai

A CSRF-támadásokat a rosszindulatú kérés kézbesítésének módja szerint osztályozzák. Minden típus más HTML-elemet használ a kérés elküldéséhez, de mindegyik a böngésző általi automatikus sütiküldésre támaszkodik. A módszer kiválasztása a támadó céljaitól függ: a GET-alapú támadások kevesebb kódot igényelnek, a POST-alapúak megbízhatóbban megkerülnek néhány védelmet, az XMLHttpRequest-alapúak pedig lehetővé teszik a fejlécek manipulálását.

GET-alapú CSRF

A legegyszerűbb módszer: a támadó elhelyez egy <img>-et az oldalon olyan URL-lel, amely tartalmazza a kérés paramétereit. A böngésző betölti a képet, és GET-kérést küld a szerverre. Például a <img src="https://api.example.com/delete?postId=123" /> törli a bejegyzést, ha a szerver a DELETE-t GET-en keresztül dolgozza fel. A nyilvánvaló veszély ellenére néhány API még mindig GET-et használ törlési vagy frissítési műveletekhez.

POST-alapú CSRF

Ha a szerver csak POST-kéréseket fogad el, a támadó létrehoz egy rejtett űrlapot POST módszerrel, és automatikusan elküldi JavaScripten keresztül. Az űrlap nem látszik a képernyőn (minden <input> type="hidden"), és az autofocus + .submit() a felhasználó kattintása nélkül működik. A POST-alapú támadások nem működnek, ha a szerver ellenőrzi a Content-Type fejlécet, de a legtöbb API elfogadja a standard application/x-www-form-urlencoded típust.

XHR-alapú CSRF (CORS-szal)

Az XMLHttpRequest vagy Fetch API lehetővé teszi kérések küldését tetszőleges fejlécekkel. Ha a szerver túl szélesen konfigurálta a CORS-t (Access-Control-Allow-Origin: *), a támadó bármilyen kérést küldhet és olvashatja a választ. Egy CSRF-támadáshoz azonban a válasz olvasása nem szükséges — a művelet végrehajtása elég. A modern böngészők preflight-kérést (OPTIONS) küldenek a nem szabványos kérések előtt, ami blokkolhatja az XHR-alapú CSRF-et, ha a szerver megfelelően van konfigurálva.

CSRF mobilalkalmazásokban

A mobilalkalmazások kevésbé sérülékenyek a CSRF-re, mint a webhelyek, mert a natív alkalmazások ritkán használnak cookie-hitelesítést. Ehelyett a mobil API-k gyakrabban alkalmaznak tokeneket az Authorization fejlécben (Bearer-tokenek, JWT). Vannak azonban olyan forgatókönyvek, ahol a CSRF-támadás lehetséges: WebView webes bejelentkezéssel, hibrid alkalmazások és cookie-alapú munkameneteket használó API-k. A TechCrunch (2025) szerint a mobilalkalmazások nyilvános API-inak körülbelül 18%-a még mindig támogatja a munkamenet-sütiket.

CSRF WebView-n keresztül

Számos alkalmazás nyit meg weboldalakat WebView-ban — OAuth-on keresztüli hitelesítés, fizetőűrlapok, tartalom megtekintése. A WebView egy teljes értékű böngésző az alkalmazáson belül, amely tárolja a munkamenet-sütiket. Ha a támadó talál egy módot a saját URL-jének betöltésére a WebView-ban (nyitott átirányításon vagy Deep Linken keresztül), pontosan úgy hajthat végre CSRF-támadást, mint egy szokásos böngészőben. Védelem — Chrome Custom Tabs vagy SFSafariViewController használata WebView helyett a kritikus műveletekhez.

CSRF JWT-hitelesítéssel rendelkező API-kban

A JWT-tokeneket általában a localStorage-ban vagy az alkalmazás memóriájában tárolják, és nem küldődnek automatikusan — a fejlesztő kifejezetten hozzáadja az Authorization fejlécet minden kéréshez. Ez lehetetlenné teszi a klasszikus CSRF-támadást. Ha azonban az alkalmazás a JWT-t sütiben tárolja (ami ritka, de előfordul), a kockázat visszatér. További védelem — a JWT hozzákötése a kérés egy adott originjéhez az azp vagy aud követelésen keresztül, ami megakadályozza a token használatát más tartományon.

// Példa a CSRF-token szerveroldali ellenőrzésére Express-ben
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// CSRF-token generálása bejelentkezéskor
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Védelmi módszerek CSRF ellen

A modern CSRF elleni védelem három szinten alapul: szerveroldali CSRF-tokenek, a SameSite attribútum sütikhez és az Origin fejléc ellenőrzése. E módszerek kombinációja 99%-os védelmet nyújt a CSRF-támadások ellen anélkül, hogy jelentősen befolyásolná a felhasználói élményt. A konkrét megközelítés kiválasztása az alkalmazás architektúrájától függ: egy webhely számára elég a SameSite=Lax, egy mobilalkalmazás API-ja tokeneket igényel a fejlécekben.

CSRF-tokenek (szinkronizátor)

Standard módszer: a szerver generál egy egyedi tokent, hozzáköti a felhasználó munkamenetéhez, és továbbítja az ügyfélnek. Az ügyfél a tokent minden állapotot módosító kérésbe belefoglalja (az űrlap rejtett mezőjében vagy az X-CSRF-Token fejlécben). A szerver összehasonlítja a kapott tokent a munkamenetben tárolttal. A tokennek kriptográfiailag biztonságosnak, véletlenszerűnek, legalább 32 bájt hosszúnak kell lennie, és minden munkamenetben vagy műveletben változnia kell. A token élettartama — legfeljebb néhány óra.

SameSite Cookie

A süti SameSite attribútuma korlátozza a sütik küldését társtartományi kérések esetén. A Lax érték csak a legfelső szintű navigációs GET-kérések esetén engedélyezi a sütik küldését — ez a legtöbb oldal számára elegendő. A Strict blokkolja a sütiket minden társtartományi kérés, beleértve a navigáció esetén is: a felhasználónak újra be kell jelentkeznie, ha egy másik oldalról lép át. A Chrome Platform Status (2026) szerint a SameSite=Lax alapértelmezetten be van kapcsolva az összes modern böngészőben, ami 67%-kal csökkentette a CSRF-támadások számát.

Origin és Referer ellenőrzése

A szerver ellenőrizheti a beérkező kérés Origin vagy Referer fejléceit. Ha a kérés másik tartományból érkezett — blokkolva lesz. Az Origin megbízhatóbb, mint a Referer, mert mindig jelen van a POST-kérésekben, és nem kapcsolható ki böngészőpolitikákkal. Implementáció: az engedélyezett origin-ek fehér listája, összehasonlítás a fejléc aktuális értékével. A módszer hatékony, de összetett a mobilalkalmazásokkal, ahol az Origin fejlécek hiányozhatnak vagy hamisíthatók.

// Példa a CSRF-token ellenőrzésére Spring Boot-ban
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

Egy olyan módszer, amely nem igényli a token tárolását a szerveren: a szerver beállít egy sütit véletlen értékkel, az ügyfél kiolvassa az értéket a sütiből, és visszaküldi a fejlécben vagy a kérés törzsében. A szerver összehasonlítja mindkét értéket. Ha a támadó nem tudja olvasni a sütit (azonos eredetű szabály), nem fogja tudni hamisítani a tokent. A módszer könnyebben implementálható, mint a szinkronizátor, de HTTPS-t igényel a süti elfogás elleni védelméhez.

• CSRF-tokenek — az arany standard: megbízható, időpróbált, minden keretrendszer által támogatott
• SameSite=Lax — minimális védelem webalkalmazásokhoz: ingyenes, automatikus, nem igényel kódot
• Origin-ellenőrzés — további szint: blokkolja a támadásokat a token ellenőrzése előtt
• Double Submit — szerveroldali munkamenet nélküli REST API-khoz: hatékony HTTPS-en
• Egyedi fejlécek — X-Requested-With: XMLHttpRequest blokkolja az egyszerű CSRF-űrlapokat

Különbség a CSRF és az XSS között

A CSRF és az XSS különböző típusú támadások, amelyeket gyakran összekevernek. A CSRF kihasználja a szerver bizalmát a felhasználó böngészőjében: a szerver végrehajtja a támadó utasítását, mert a kérés érvényes sütikkel érkezik. Az XSS kihasználja a böngésző bizalmát a szerver tartalmában: a böngésző végrehajtja a támadó által az oldalba injektált szkriptet. A CSRF nem igényel kódinjektálást a céloldalon — elég egy kérést küldeni egy másik tartományból. Az XSS ezzel szemben megköveteli, hogy a támadó megtalálja a saját JavaScriptjének az oldal HTML-kódjába való injektálásának módját. Ezenkívül az XSS megkerülheti a CSRF-védelmet: az injektált szkript kiolvassa a CSRF-tokent az oldalról, és elküldi a kéréssel együtt.

A CSRF és az XSS közötti különbség megértése kritikus fontosságú a többrétegű védelem kiépítéséhez. A CSRF-tokenek nem védenek az XSS ellen, a CSP (Content Security Policy) pedig nem véd a CSRF ellen. Csak a módszerek kombinációja biztosítja az alkalmazás biztonságát mindkét támadástípus ellen. A WebView-val rendelkező mobilalkalmazásokban a kockázatok megkétszereződnek, ezért a fejlesztőknek legalább CSRF-tokeneket az API-kérésekhez és Content Security Policy-t a webes tartalomhoz ajánlott alkalmazniuk.