CSRF în dezvoltarea mobilă: esența, tipurile de atacuri și metodele de protecție

Ce este un atac CSRF?

CSRF (Cross-Site Request Forgery) este un atac în care atacatorul creează o cerere falsificată și forțează browserul victimei să o trimită pe serverul țintă. Serverul execută cererea deoarece primește cookie-credentials valide ale sesiunii curente a utilizatorului. Atacul este posibil deoarece browserul adaugă automat cookie-uri la fiecare cerere către domeniul țintă, indiferent de pagina de pe care a fost trimisă cererea. Utilizatorul s-ar putea să nu fi văzut pagina atacatorului — este suficient să se încarce un <img>, <form> sau <iframe> ascuns cu un URL malefic. CSRF nu fură date direct — atacul execută acțiuni în numele victimei (operații de schimbare a stării), cum ar fi transferul de bani, schimbarea parolei sau ștergerea contului.

Care operații sunt cele mai vulnerabile?

Atacurile CSRF vizează exclusiv operațiile care modifică starea — cereri GET cu efecte secundare, POST, PUT și DELETE. De exemplu, o cerere de schimbare a adresei de email în contul personal: dacă serverul acceptă cererea fără a verifica originea, atacatorul poate înlocui adresa cu a sa și poate iniția resetarea parolei. Atacul este deosebit de periculos pentru sistemele bancare, panourile de administrare și rețelele sociale, unde o singură acțiune are consecințe grave. API-urile aplicațiilor mobile care folosesc cookie-uri pentru autentificare sunt, de asemenea, susceptibile la CSRF dacă nu aplică verificări suplimentare.

Cine este în zona de risc?

Sub atac cad orice aplicații web și API-uri unde autentificarea se bazează pe cookie, iar serverul nu verifică originea cererii. Aplicațiile mobile care folosesc WebView pentru autentificare prin formulare web sunt, de asemenea, vulnerabile: componenta browserului trimite automat cookie-urile, iar atacatorul poate injecta o cerere malefică prin încărcare în fundal. Potrivit HackerOne (2025), aproximativ 12% din toate rapoartele de vulnerabilități în aplicațiile web sunt legate de lipsa protecției împotriva CSRF.

Ce face CSRF periculos?

Caracteristica principală a CSRF este invizibilitatea pentru victimă. Utilizatorul poate nici măcar să nu bănuiască că atacul a avut loc: cererea falsificată se execută în fundal, iar interfața aplicației nu arată semne de spargere. Singura modalitate de a detecta CSRF este monitorizarea jurnalelor serverului sau modificări bruște în cont. În plus, CSRF se combină ușor cu alte vulnerabilități, cum ar fi XSS sau redirecționările deschise, ceea ce multiplică de mai multe ori daunele.

Cum funcționează un atac CSRF?

Atacul CSRF constă din trei condiții obligatorii: victima este autentificată pe site-țintă, serverul folosește autentificare prin cookie, iar cererea atacatorului este direcționată către URL-ul acțiunii. Atacatorul creează o pagină HTML cu un formular, script sau imagine al cărei atribut src indică URL-ul țintă. Browserul victimei încarcă această pagină și trimite automat cererea pe server împreună cu cookie-ul sesiunii curente. Serverul primește cookie-uri valide, nu verifică sursa cererii și execută operația.

<!-- Exemplu de atac CSRF printr-un formular ascuns -->
<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>

După încărcarea paginii, scriptul trimite imediat formularul. Browserul atașează cookie-ul de sesiune al utilizatorului la cererea POST către bank.example.com. Serverul băncii verifică cookie-ul, confirmă autentificarea utilizatorului și efectuează transferul în contul atacatorului. Victima vede o pagină goală sau legitimă, iar banii au fost deja debitați.

Rolul browserului în CSRF

Caracteristica cheie a protocolului HTTP — absența verificării încorporate a sursei cererii. Browserul adaugă cookie-ul la cerere dacă domeniul cererii coincide cu domeniul cookie-ului. Atacatorul nu trebuie să cunoască conținutul cookie-ului — browserul face acest lucru automat. Same-origin policy nu protejează împotriva CSRF, deoarece atacul vizează serverul, nu citirea răspunsului. Mecanisme precum CORS sunt, de asemenea, neputincioase: cererile CSRF nu necesită de obicei citirea răspunsului pentru a provoca daune.

Principalele tipuri de atacuri CSRF

Atacurile CSRF se clasifică după metoda de livrare a cererii malefice. Fiecare tip folosește un element HTML diferit pentru a trimite cererea, dar toate se bazează pe trimiterea automată a cookie-urilor de către browser. Alegerea metodei depinde de obiectivele atacatorului: atacurile GET-based necesită mai puțin cod, POST-based ocolesc mai sigur unele protecții, iar XMLHttpRequest-based permit manipularea header-elor.

GET-based CSRF

Cea mai simplă metodă: atacatorul plasează pe pagină un <img> cu un URL care conține parametrii cererii. Browserul încarcă imaginea și trimite o cerere GET pe server. De exemplu, <img src="https://api.example.com/delete?postId=123" /> șterge înregistrarea dacă serverul procesează DELETE prin GET. În ciuda pericolului evident, unele API-țuri încă mai folosesc GET pentru operații de ștergere sau actualizare.

POST-based CSRF

Dacă serverul acceptă doar cereri POST, atacatorul creează un formular ascuns cu metoda POST și îl trimite automat prin JavaScript. Formularul nu este afișat pe ecran (toate <input> au type="hidden"), iar autofocus + .submit() funcționează fără clicul utilizatorului. Atacurile POST-based nu funcționează dacă serverul verifică header-ul Content-Type, dar majoritatea API-urilor acceptă application/x-www-form-urlencoded standard.

XHR-based CSRF (cu CORS)

XMLHttpRequest sau Fetch API permit trimiterea de cereri cu header-e arbitrare. Dacă serverul a configurat CORS prea larg (Access-Control-Allow-Origin: *), atacatorul poate trimite orice cerere și citi răspunsul. Cu toate acestea, pentru un atac CSRF citirea răspunsului nu este necesară — este suficientă executarea acțiunii. Browserele moderne trimit o cerere preflight OPTIONS înainte de cererile non-standard, ceea ce poate bloca XHR-based CSRF dacă serverul este configurat corect.

CSRF în aplicațiile mobile

Aplicațiile mobile sunt mai puțin vulnerabile la CSRF decât site-urile web, deoarece aplicațiile native folosesc rareori autentificarea prin cookie. În schimb, API-urile mobile aplică mai des token-uri în header-ul Authorization (token-uri Bearer, JWT). Totuși, există scenarii în care un atac CSRF este posibil: WebView cu autentificare web, aplicații hibride și API-uri cu sesiuni bazate pe cookie. Potrivit TechCrunch (2025), aproximativ 18% din API-urile publice ale aplicațiilor mobile încă mai suportă cookie-uri de sesiune.

CSRF prin WebView

Multe aplicații deschid pagini web în WebView — autentificare prin OAuth, formulare de plată, vizualizare de conținut. WebView este un browser complet în interiorul aplicației care stochează cookie-uri de sesiune. Dacă atacatorul găsește o modalitate de a-și încărca propriul URL în WebView (printr-o redirecționare deschisă sau Deep Link), poate executa un atac CSRF exact ca într-un browser obișnuit. Protecție — folosirea Chrome Custom Tabs sau SFSafariViewController în loc de WebView pentru operații critice.

CSRF în API-uri cu autentificare JWT

Token-urile JWT sunt de obicei stocate în localStorage sau în memoria aplicației și nu sunt trimise automat — dezvoltatorul adaugă explicit header-ul Authorization la fiecare cerere. Acest lucru face imposibil atacul CSRF clasic. Totuși, dacă aplicația stochează JWT în cookie (ceea ce este rar, dar se întâmplă), riscul revine. Protecție suplimentară — legarea JWT de o origine specifică a cererii prin claim-ul azp sau aud, ceea ce previne utilizarea token-ului pe un alt domeniu.

// Exemplu de verificare pe server a token-ului CSRF în 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();
};

// Generarea token-ului CSRF la autentificare
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Metode de protecție împotriva CSRF

Protecția modernă împotriva CSRF se bazează pe trei niveluri: token-uri CSRF pe server, atributul SameSite pentru cookie și verificarea header-ului Origin. Combinarea acestor metode asigură protecție împotriva a 99% din atacurile CSRF fără un impact semnificativ asupra UX. Alegerea abordării specifice depinde de arhitectura aplicației: unui site web îi este suficient SameSite=Lax, API-ul unei aplicații mobile necesită token-uri în header-e.

Token-uri CSRF (sincronizator)

Metoda standard: serverul generează un token unic, îl leagă de sesiunea utilizatorului și îl transmite clientului. Clientul include token-ul în fiecare cerere care modifică starea (în câmpul ascuns al formularului sau header-ul X-CSRF-Token). Serverul compară token-ul primit cu cel stocat în sesiune. Token-ul trebuie să fie criptografic sigur, aleatoriu, de cel puțin 32 de octeți și să se schimbe la fiecare sesiune sau operație. Durata de viață a token-ului — nu mai mult de câteva ore.

SameSite Cookie

Atributul SameSite pentru cookie limitează trimiterea cookie-urilor la cererile cross-domain. Valoarea Lax permite trimiterea cookie-urilor doar pentru cererile GET de navigare de nivel superior — acest lucru este suficient pentru majoritatea site-urilor. Strict blochează cookie-urile pentru toate cererile cross-domain, inclusiv navigarea: utilizatorul va trebui să se autentifice din nou la trecerea de pe un alt site. Potrivit Chrome Platform Status (2026), SameSite=Lax este activat implicit în toate browserele moderne, ceea ce a redus numărul de atacuri CSRF cu 67%.

Verificarea Origin și Referer

Serverul poate verifica header-ele Origin sau Referer ale cererii primite. Dacă cererea provine de pe un alt domeniu — este blocată. Origin este mai fiabil decât Referer, deoarece este întotdeauna prezent în cererile POST și nu este dezactivat de politicile browserului. Implementare: o listă albă de origin-uri permise, compararea cu valoarea curentă a header-ului. Metoda este eficientă, dar complexă cu aplicațiile mobile, unde header-ele Origin pot lipsi sau pot fi falsificate.

// Exemplu de verificare a token-ului CSRF în 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

Metodă care nu necesită stocarea token-ului pe server: serverul setează un cookie cu o valoare aleatorie, clientul citește valoarea din cookie și o trimite înapoi în header-ul sau corpul cererii. Serverul compară ambele valori. Dacă atacatorul nu poate citi cookie-ul (Same-origin policy), nu va putea falsifica token-ul. Metoda este mai ușor de implementat decât sincronizatorul, dar necesită HTTPS pentru a proteja cookie-ul de interceptare.

• Token-uri CSRF — standardul de aur: fiabile, testate în timp, suportate de toate framework-urile
• SameSite=Lax — protecție minimă pentru aplicații web: gratuită, automată, fără a necesita cod
• Verificarea Origin — nivel suplimentar: blochează atacurile înainte de verificarea token-ului
• Double Submit — pentru REST API fără sesiuni server-side: eficient pe HTTPS
• Header-e personalizate — X-Requested-With: XMLHttpRequest blochează formularele CSRF simple

Diferența dintre CSRF și XSS

CSRF și XSS sunt tipuri diferite de atacuri care sunt adesea confundate. CSRF exploatează încrederea serverului în browserul utilizatorului: serverul execută comanda atacatorului deoarece cererea vine cu cookie-uri valide. XSS exploatează încrederea browserului în conținutul serverului: browserul execută scriptul injectat de atacator în pagină. CSRF nu necesită injectarea de cod pe site-țintă — este suficient să trimiți o cerere de pe un alt domeniu. XSS, dimpotrivă, necesită găsirea unei modalități de a injecta propriul JavaScript în codul HTML al paginii. În plus, XSS poate ocoli protecția CSRF: scriptul injectat citește token-ul CSRF din pagină și îl trimite împreună cu cererea.

Înțelegerea diferenței dintre CSRF și XSS este critică pentru construirea unei protecții multinivel. Token-urile CSRF nu protejează împotriva XSS, iar CSP (Content Security Policy) nu protejează împotriva CSRF. Doar combinarea metodelor asigură securitatea aplicației împotriva ambelor tipuri de atacuri. în aplicațiile mobile cu WebView riscurile se dublează, de aceea dezvoltatorilor li se recomandă să aplice cel puțin token-uri CSRF pentru cererile API și Content Security Policy pentru conținutul web.