CSRF i mobil utveckling: essens, attacktyper och skyddsmetoder

Vad är en CSRF-attack?

CSRF (Cross-Site Request Forgery) är en attack där angriparen skapar en förfalskad begäran och tvingar offrets webbläsare att skicka den till målservern. Servern utför begäran eftersom den tar emot giltiga cookie-credentials för den aktuella användarsessionen. Attacken är möjlig eftersom webbläsaren automatiskt lägger till cookies till varje begäran till måldomänen, oavsett från vilken sida begäran skickades. Användaren kanske inte ens har sett angriparens sida — det räcker att ladda en dold <img>, <form> eller <iframe> med en skadlig URL. CSRF stjäl inte data direkt — attacken utför åtgärder för offrets räkning (tillståndsändrande operationer), såsom att överföra pengar, ändra lösenord eller radera konto.

Vilka operationer är mest sårbara?

CSRF-attacker riktar sig uteslutande mot tillståndsändrande operationer — GET-begäranden med bieffekter, POST, PUT och DELETE. Till exempel en begäran om att ändra e-postadress i det personliga kontot: om servern accepterar begäran utan att kontrollera ursprunget kan angriparen byta ut sin egen e-postadress och initiera en lösenordsåterställning. Attacken är särskilt farlig för banksystem, administrationspaneler och sociala nätverk, där en enda åtgärd får allvarliga konsekvenser. API:er för mobila applikationer som använder cookies för autentisering är också mottagliga för CSRF om de inte tillämpar ytterligare kontroller.

Vem är i riskzonen?

Alla webbapplikationer och API:er där autentisering baseras på cookies och servern inte kontrollerar begärans ursprung är i riskzonen. Mobila applikationer som använder WebView för auktorisering via webbformulär är också sårbara: webbläsarkomponenten skickar automatiskt cookies och angriparen kan injicera en skadlig begäran genom bakgrundsladdning. Enligt HackerOne (2025) är cirka 12% av alla sårbarhetsrapporter i webbapplikationer relaterade till avsaknad av CSRF-skydd.

Vad gör CSRF farligt?

Huvudegenskapen hos CSRF är osynligheten för offret. Användaren kanske inte ens misstänker att en attack har inträffat: den förfalskade begäran körs i bakgrunden och applikationsgränssnittet visar inga tecken på intrång. Det enda sättet att upptäcka CSRF är att övervaka serverloggar eller plötsliga förändringar i kontot. Dessutom kombineras CSRF lätt med andra sårbarheter, såsom XSS eller öppna omdirigeringar, vilket mångdubblar skadan.

Hur fungerar en CSRF-attack?

En CSRF-attack består av tre obligatoriska villkor: offret är auktoriserat på målwebbplatsen, servern använder cookie-autentisering och angriparens begäran riktas till åtgärdens URL. Angriparen skapar en HTML-sida med ett formulär, skript eller bild vars src-attribut pekar på mål-URL:en. Offrets webbläsare laddar denna sida och skickar automatiskt begäran till servern tillsammans med cookien för den aktuella sessionen. Servern tar emot giltiga cookies, kontrollerar inte begärans källa och utför operationen.

<!-- Exempel på CSRF-attack via ett dolt formulär -->
<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>

Efter att sidan laddats skickar skriptet omedelbart formuläret. Webbläsaren bifogar användarens scookie till POST-begäran till bank.example.com. Bankens server kontrollerar cookien, bekräftar att användaren är autentiserad och utför överföringen till angriparens konto. Offret ser en tom eller legitim sida och pengarna har redan dragits.

Webbläsarens roll i CSRF

Nyckelegenskapen hos HTTP-protokollet — avsaknaden av inbyggd källkontroll av begäran. Webbläsaren lägger till cookien till begäran om begärans domän matchar cookiens domän. Angriparen behöver inte känna till cookiens innehåll — webbläsaren gör detta automatiskt. Same-origin policy skyddar inte mot CSRF eftersom attacken riktar sig mot servern, inte mot att läsa svaret. Mekanismer som CORS är också maktlösa: CSRF-begäranden kräver vanligtvis inte att svaret läses för att orsaka skada.

Huvudtyper av CSRF-attacker

CSRF-attacker klassificeras baserat på hur den skadliga begäran levereras. Varje typ använder ett annat HTML-element för att skicka begäran, men alla förlitar sig på automatisk sändning av cookies av webbläsaren. Valet av metod beror på angriparens mål: GET-baserade attacker kräver mindre kod, POST-baserade kringgår vissa skydd mer tillförlitligt och XMLHttpRequest-baserade möjliggör manipulering av rubriker.

GET-baserad CSRF

Den enklaste metoden: angriparen placerar en <img> på sidan med en URL som innehåller begärans parametrar. Webbläsaren laddar bilden och skickar en GET-begäran till servern. Till exempel tar <img src="https://api.example.com/delete?postId=123" /> bort posten om servern bearbetar DELETE via GET. Trots den uppenbara faran använder vissa API:er fortfarande GET för borttagnings- eller uppdateringsoperationer.

POST-baserad CSRF

Om servern endast accepterar POST-begäranden skapar angriparen ett dolt formulär med POST-metoden och skickar det automatiskt via JavaScript. Formuläret visas inte på skärmen (alla <input> har type="hidden") och autofocus + .submit() fungerar utan användarens klick. POST-baserade attacker fungerar inte om servern kontrollerar Content-Type-rubriken, men de flesta API:er accepterar standard application/x-www-form-urlencoded.

XHR-baserad CSRF (med CORS)

XMLHttpRequest eller Fetch API gör det möjligt att skicka begäranden med godtyckliga rubriker. Om servern har konfigurerat CORS för brett (Access-Control-Allow-Origin: *) kan angriparen skicka vilken begäran som helst och läsa svaret. För en CSRF-attack är det dock inte nödvändigt att läsa svaret — det räcker att utföra åtgärden. Moderna webbläsare skickar en preflight-begäran OPTIONS före icke-standardiserade begäranden, vilket kan blockera XHR-baserad CSRF om servern är korrekt konfigurerad.

CSRF i mobila applikationer

Mobila applikationer är mindre mottagliga för CSRF än webbplatser, eftersom inbyggda applikationer sällan använder cookie-autentisering. Istället tillämpar mobila API:er oftare tokens i Authorization-rubriken (Bearer-tokens, JWT). Det finns dock scenarier där en CSRF-attack är möjlig: WebView med webbinloggning, hybridapplikationer och API:er med cookie-baserade sessioner. Enligt TechCrunch (2025) stöder cirka 18% av de offentliga API:erna för mobila applikationer fortfarande sessionscookies.

CSRF via WebView

Många applikationer öppnar webbsidor i WebView — auktorisering via OAuth, betalningsformulär, visning av innehåll. WebView är en fullständig webbläsare inuti applikationen som lagrar sessionscookies. Om angriparen hittar ett sätt att ladda sin egen URL i WebView (genom en öppen omdirigering eller Deep Link) kan den utföra en CSRF-attack precis som i en vanlig webbläsare. Skydd — användning av Chrome Custom Tabs eller SFSafariViewController istället för WebView för kritiska operationer.

CSRF i API:er med JWT-autentisering

JWT-tokens lagras vanligtvis i localStorage eller i applikationens minne och skickas inte automatiskt — utvecklaren lägger explicit till Authorization-rubriken till varje begäran. Detta gör en klassisk CSRF-attack omöjlig. Men om applikationen lagrar JWT i en cookie (vilket är sällsynt men förekommer) återvänder risken. Extra skydd — att binda JWT till en specifik ursprungsort för begäran via azp- eller aud-anspråket, vilket förhindrar användning av token på en annan domän.

// Exempel på servervalidering av CSRF-token i 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();
};

// Generering av CSRF-token vid inloggning
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Skyddsmetoder mot CSRF

Modernt CSRF-skydd bygger på tre nivåer: serverbaserade CSRF-tokens, SameSite-attributet för cookies och verifiering av Origin-rubriken. Kombinationen av dessa metoder ger skydd mot 99% av CSRF-attacker utan betydande påverkan på användarupplevelsen. Valet av specifik metod beror på applikationens arkitektur: en webbplats kan använda SameSite=Lax, medan en mobil applikations API kräver tokens i rubrikerna.

CSRF-tokens (synkronisator)

Standardmetod: servern genererar en unik token, binder den till användarens session och överför den till klienten. Klienten inkluderar token i varje tillståndsändrande begäran (i ett dolt formulärfält eller X-CSRF-Token-rubriken). Servern jämför den mottagna token med den som lagrats i sessionen. Token måste vara kryptografiskt säker, slumpmässig, minst 32 byte lång och ändras vid varje session eller operation. Tokenens livslängd — högst några timmar.

SameSite Cookie

SameSite-attributet för cookies begränsar sändningen av cookies vid cross-domänbegäranden. Värdet Lax tillåter sändning av cookies endast för navigerings-GET-begäranden på högsta nivå — detta räcker för de flesta webbplatser. Strict blockerar cookies för alla cross-domänbegäranden, inklusive navigering: användaren måste logga in igen när den kommer från en annan webbplats. Enligt Chrome Platform Status (2026) är SameSite=Lax aktiverat som standard i alla moderna webbläsare, vilket har minskat antalet CSRF-attacker med 67%.

Verifiering av Origin och Referer

Servern kan kontrollera Origin- eller Referer-rubrikerna för inkommande begäran. Om begäran kommer från en annan domän blockeras den. Origin är mer tillförlitligt än Referer eftersom det alltid är närvarande i POST-begäranden och inte inaktiveras av webbläsarpolicyer. Implementering: en vitlista med tillåtna origins, jämförelse med rubrikens aktuella värde. Metoden är effektiv men komplex med mobila applikationer där Origin-rubriker kan saknas eller förfalskas.

// Exempel på validering av CSRF-token i 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

En metod som inte kräver lagring av token på servern: servern ställer in en cookie med ett slumpmässigt värde, klienten läser värdet från cookien och skickar tillbaka det i rubriken eller begärans brödtext. Servern jämför båda värdena. Om angriparen inte kan läsa cookien (Same-origin policy) kan den inte förfalska token. Metoden är enklare att implementera än synkronisatorn men kräver HTTPS för att skydda cookien från avlyssning.

• CSRF-tokens — guldstandarden: tillförlitliga, tidsbeprövade, stöds av alla ramverk
• SameSite=Lax — minimalt skydd för webbapplikationer: gratis, automatiskt, kräver ingen kod
• Origin-verifiering — extra nivå: blockerar attacker innan token kontrolleras
• Double Submit — för REST API utan serverbaserade sessioner: effektivt på HTTPS
• Anpassade rubriker — X-Requested-With: XMLHttpRequest blockerar enkla CSRF-formulär

Skillnad mellan CSRF och XSS

CSRF och XSS är olika typer av attacker som ofta förväxlas. CSRF utnyttjar serverns förtroende för användarens webbläsare: servern utför angriparens kommando eftersom begäran kommer med giltiga cookies. XSS utnyttjar webbläsarens förtroende för serverns innehåll: webbläsaren utför ett skript som angriparen injicerat på sidan. CSRF kräver inte injicering av kod på målwebbplatsen — det räcker att skicka en begäran från en annan domän. XSS å andra sidan kräver att man hittar ett sätt att injicera sin egen JavaScript i sidans HTML-kod. Dessutom kan XSS kringgå CSRF-skydd: det injicerade skriptet läser CSRF-token från sidan och skickar den tillsammans med begäran.

Att förstå skillnaden mellan CSRF och XSS är avgörande för att bygga flernivåskydd. CSRF-tokens skyddar inte mot XSS och CSP (Content Security Policy) skyddar inte mot CSRF. Endast en kombination av metoder säkerställer applikationens säkerhet mot båda typerna av attacker. I mobila applikationer med WebView fördubblas riskerna, därför rekommenderas utvecklare att använda minst CSRF-tokens för API-begäranden och Content Security Policy för webbinnehåll.