CSRF in mobiele ontwikkeling: essentie, aanvalstypen en beschermingsmethoden

Wat is een CSRF-aanval?

CSRF (Cross-Site Request Forgery) is een aanval waarbij de aanvaller een vervalst verzoek creëert en de browser van het slachtoffer dwingt dit naar de doelserver te sturen. De server voert het verzoek uit omdat het geldige cookie-credentials van de huidige gebruikerssessie ontvangt. De aanval is mogelijk omdat de browser automatisch cookies toevoegt aan elk verzoek aan het doeldomein, ongeacht van welke pagina het verzoek is verzonden. De gebruiker heeft de pagina van de aanvaller mogelijk niet eens gezien — het volstaat om een verborgen <img>, <form> of <iframe> met een kwaadaardige URL te laden. CSRF steelt geen gegevens direct — de aanval voert acties uit namens het slachtoffer (state-changing operations), zoals geld overmaken, wachtwoord wijzigen of account verwijderen.

Welke bewerkingen zijn het meest kwetsbaar?

CSRF-aanvallen zijn uitsluitend gericht op bewerkingen die de status wijzigen — GET-verzoeken met bijwerkingen, POST, PUT en DELETE. Bijvoorbeeld een verzoek om het e-mailadres te wijzigen in het gebruikersaccount: als de server het verzoek accepteert zonder de herkomst te controleren, kan de aanvaller zijn eigen e-mailadres invoeren en een wachtwoordreset initiëren. De aanval is bijzonder gevaarlijk voor banksystemen, beheerderspanelen en sociale netwerken, waar één handeling ernstige gevolgen heeft. API's van mobiele applicaties die cookies gebruiken voor authenticatie, zijn ook vatbaar voor CSRF als ze geen aanvullende controles toepassen.

Wie loopt er risico?

Alle webapplicaties en API's waar authenticatie gebaseerd is op cookies en de server de herkomst van het verzoek niet controleert, lopen risico. Mobiele applicaties die WebView gebruiken voor autorisatie via webformulieren zijn ook kwetsbaar: de browsercomponent verzendt automatisch cookies en de aanvaller kan via achtergrond laden een kwaadaardig verzoek injecteren. Volgens HackerOne (2025) heeft ongeveer 12% van alle kwetsbaarheidsrapporten in webapplicaties betrekking op het ontbreken van CSRF-bescherming.

Wat maakt CSRF gevaarlijk?

Het belangrijkste kenmerk van CSRF is onzichtbaarheid voor het slachtoffer. De gebruiker heeft mogelijk niet eens door dat er een aanval heeft plaatsgevonden: het vervalste verzoek wordt op de achtergrond uitgevoerd en de applicatie-interface vertoont geen tekenen van inbraak. De enige manier om CSRF te detecteren is het monitoren van serverlogs of plotselinge wijzigingen in het account. Bovendien combineert CSRF gemakkelijk met andere kwetsbaarheden, zoals XSS of open redirects, waardoor de schade meerdere keren wordt vergroot.

Hoe werkt een CSRF-aanval?

Een CSRF-aanval bestaat uit drie vereiste voorwaarden: het slachtoffer is geautoriseerd op de doelsite, de server gebruikt cookie-authenticatie en het verzoek van de aanvaller is gericht op de action-URL. De aanvaller maakt een HTML-pagina met een formulier, script of afbeelding waarvan het src-attribuut naar de doel-URL verwijst. De browser van het slachtoffer laadt deze pagina en stuurt automatisch het verzoek naar de server samen met de cookie van de huidige sessie. De server ontvangt geldige cookies, controleert de bron van het verzoek niet en voert de bewerking uit.

<!-- Voorbeeld van een CSRF-aanval via een verborgen formulier -->
<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>

Na het laden van de pagina verzendt het script onmiddellijk het formulier. De browser voegt de sessiecookie van de gebruiker toe aan het POST-verzoek naar bank.example.com. De bankserver controleert de cookie, bevestigt dat de gebruiker geauthenticeerd is en voert de overschrijving uit naar de rekening van de aanvaller. Het slachtoffer ziet een lege of legitieme pagina en het geld is reeds overgemaakt.

De rol van de browser bij CSRF

Het belangrijkste kenmerk van het HTTP-protocol — het ontbreken van ingebouwde herkomstcontrole van het verzoek. De browser voegt de cookie aan het verzoek toe als het domein van het verzoek overeenkomt met het domein van de cookie. De aanvaller hoeft de inhoud van de cookie niet te kennen — de browser doet dit automatisch. Same-origin policy beschermt niet tegen CSRF omdat de aanval gericht is op de server, niet op het lezen van het antwoord. Mechanismen zoals CORS zijn ook machteloos: CSRF-verzoeken vereisen gewoonlijk geen lezen van het antwoord om schade te veroorzaken.

Belangrijkste typen CSRF-aanvallen

CSRF-aanvallen worden geclassificeerd op basis van de manier waarop het kwaadaardige verzoek wordt afgeleverd. Elk type gebruikt een ander HTML-element om het verzoek te verzenden, maar ze vertrouwen allemaal op het automatisch verzenden van cookies door de browser. De keuze van de methode hangt af van de doelen van de aanvaller: GET-gebaseerde aanvallen vereisen minder code, POST-gebaseerde omzeilen sommige beschermingen betrouwbaarder en XMLHttpRequest-gebaseerde maken manipulatie van headers mogelijk.

GET-based CSRF

De eenvoudigste methode: de aanvaller plaatst een <img> op de pagina met een URL die de verzoekparameters bevat. De browser laadt de afbeelding en stuurt een GET-verzoek naar de server. Bijvoorbeeld <img src="https://api.example.com/delete?postId=123" /> verwijdert het bericht als de server DELETE via GET verwerkt. Ondanks het duidelijke gevaar gebruiken sommige API's nog steeds GET voor verwijder- of updatebewerkingen.

POST-based CSRF

Als de server alleen POST-verzoeken accepteert, maakt de aanvaller een verborgen formulier met de POST-methode en verzendt deze automatisch via JavaScript. Het formulier wordt niet op het scherm weergegeven (alle <input> hebben type="hidden") en autofocus + .submit() werkt zonder klik van de gebruiker. POST-gebaseerde aanvallen werken niet als de server de Content-Type-header controleert, maar de meeste API's accepteren de standaard application/x-www-form-urlencoded.

XHR-based CSRF (met CORS)

XMLHttpRequest of Fetch API maken het mogelijk verzoeken met willekeurige headers te verzenden. Als de server CORS te breed heeft geconfigureerd (Access-Control-Allow-Origin: *), kan de aanvaller elk verzoek verzenden en het antwoord lezen. Voor een CSRF-aanval is het lezen van het antwoord echter niet noodzakelijk — het uitvoeren van de actie is voldoende. Moderne browsers sturen een preflight-verzoek OPTIONS voor niet-standaard verzoeken, wat XHR-based CSRF kan blokkeren als de server correct is geconfigureerd.

CSRF in mobiele applicaties

Mobiele applicaties zijn minder vatbaar voor CSRF dan websites, omdat native applicaties zelden cookie-authenticatie gebruiken. In plaats daarvan gebruiken mobiele API's vaker tokens in de Authorization-header (Bearer-tokens, JWT). Er zijn echter scenario's waarin een CSRF-aanval mogelijk is: WebView met weblogin, hybride applicaties en API's met cookie-gebaseerde sessies. Volgens TechCrunch (2025) ondersteunt ongeveer 18% van de openbare API's van mobiele applicaties nog steeds sessiecookies.

CSRF via WebView

Veel applicaties openen webpagina's in WebView — authenticatie via OAuth, betalingsformulieren, inhoud bekijken. WebView is een volledige browser binnen de applicatie die sessiecookies opslaat. Als de aanvaller een manier vindt om zijn eigen URL in WebView te laden (via een open redirect of Deep Link), kan hij een CSRF-aanval uitvoeren precies zoals in een gewone browser. Bescherming — gebruik van Chrome Custom Tabs of SFSafariViewController in plaats van WebView voor kritieke bewerkingen.

CSRF in API's met JWT-authenticatie

JWT-tokens worden meestal opgeslagen in localStorage of in het geheugen van de applicatie en worden niet automatisch verzonden — de ontwikkelaar voegt expliciet de Authorization-header toe aan elk verzoek. Dit maakt een klassieke CSRF-aanval onmogelijk. Als de applicatie JWT echter in een cookie opslaat (wat zeldzaam is maar voorkomt), keert het risico terug. Extra bescherming — het binden van JWT aan een specifieke origin van het verzoek via de azp- of aud-claim, wat gebruik van het token op een ander domein voorkomt.

// Voorbeeld van server-side CSRF-tokenvalidatie in Express
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();
};

// Genereren van CSRF-token bij inloggen
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Beschermingsmethoden tegen CSRF

Moderne CSRF-bescherming is gebaseerd op drie niveaus: server-side CSRF-tokens, het SameSite-attribuut voor cookies en verificatie van de Origin-header. Combinatie van deze methoden biedt bescherming tegen 99% van CSRF-aanvallen zonder significante impact op UX. De keuze van de specifieke benadering hangt af van de architectuur van de applicatie: voor een website is SameSite=Lax voldoende, voor de API van een mobiele applicatie zijn tokens in headers nodig.

CSRF-tokens (synchronisator)

Standaardmethode: de server genereert een uniek token, koppelt het aan de gebruikerssessie en geeft het door aan de client. De client neemt het token op in elk statuswijzigend verzoek (in een verborgen formulierveld of de X-CSRF-Token-header). De server vergelijkt het ontvangen token met het in de sessie opgeslagen token. Het token moet cryptografisch veilig, willekeurig, minimaal 32 bytes lang zijn en bij elke sessie of bewerking veranderen. De levensduur van het token — niet meer dan enkele uren.

SameSite Cookie

Het SameSite-attribuut voor cookies beperkt het verzenden van cookies bij cross-domein verzoeken. De waarde Lax staat verzenden van cookies alleen toe voor navigatie-GET-verzoeken van het hoogste niveau — dit is voldoende voor de meeste sites. Strict blokkeert cookies voor alle cross-domein verzoeken, inclusief navigatie: de gebruiker moet opnieuw inloggen bij het overstappen van een andere site. Volgens Chrome Platform Status (2026) is SameSite=Lax standaard ingeschakeld in alle moderne browsers, wat het aantal CSRF-aanvallen met 67% heeft verminderd.

Verificatie van Origin en Referer

De server kan de Origin- of Referer-headers van het inkomende verzoek controleren. Als het verzoek van een ander domein komt — wordt het geblokkeerd. Origin is betrouwbaarder dan Referer omdat het altijd aanwezig is in POST-verzoeken en niet wordt uitgeschakeld door browserbeleid. Implementatie: een witte lijst van toegestane origins, vergelijking met de huidige waarde van de header. De methode is effectief, maar complex met mobiele applicaties waar Origin-headers kunnen ontbreken of worden vervalst.

// Voorbeeld van CSRF-tokenvalidatie in Spring Boot
@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

Een methode die geen opslag van het token op de server vereist: de server stelt een cookie in met een willekeurige waarde, de client leest de waarde uit de cookie en stuurt deze terug in de header of body van het verzoek. De server vergelijkt beide waarden. Als de aanvaller de cookie niet kan lezen (Same-origin policy), kan hij het token niet vervalsen. De methode is eenvoudiger te implementeren dan de synchronisator, maar vereist HTTPS om de cookie te beschermen tegen onderschepping.

• CSRF-tokens — de gouden standaard: betrouwbaar, door de tijd getest, ondersteund door alle frameworks
• SameSite=Lax — minimale bescherming voor webapplicaties: gratis, automatisch, geen code nodig
• Origin-verificatie — extra niveau: blokkeert aanvallen voordat het token wordt gecontroleerd
• Double Submit — voor REST API's zonder server-side sessies: effectief op HTTPS
• Aangepaste headers — X-Requested-With: XMLHttpRequest blokkeert eenvoudige CSRF-formulieren

Verschil tussen CSRF en XSS

CSRF en XSS zijn verschillende soorten aanvallen die vaak worden verward. CSRF maakt misbruik van het vertrouwen van de server in de browser van de gebruiker: de server voert het commando van de aanvaller uit omdat het verzoek met geldige cookies komt. XSS maakt misbruik van het vertrouwen van de browser in de inhoud van de server: de browser voert een script uit dat door de aanvaller in de pagina is geïnjecteerd. CSRF vereist geen injectie van code op de doelsite — het volstaat om een verzoek vanaf een ander domein te verzenden. XSS vereist daarentegen het vinden van een manier om eigen JavaScript in de HTML-code van de pagina te injecteren. Bovendien kan XSS CSRF-bescherming omzeilen: het geïnjecteerde script leest het CSRF-token van de pagina en verzendt het samen met het verzoek.

Het begrijpen van het verschil tussen CSRF en XSS is cruciaal voor het bouwen van meerlaagse bescherming. CSRF-tokens beschermen niet tegen XSS en CSP (Content Security Policy) beschermt niet tegen CSRF. Alleen een combinatie van methoden zorgt voor de beveiliging van de applicatie tegen beide soorten aanvallen. In mobiele applicaties met WebView verdubbelen de risico's, daarom wordt ontwikkelaars aangeraden om ten minste CSRF-tokens voor API-verzoeken en Content Security Policy voor webinhoud toe te passen.