Cross site scripting

Cross-site scripting, afgekort als XSS, is een webkwetsbaarheid waarbij een aanvaller kwaadaardige scripts injecteert in webpagina's die andere gebruikers bekijken. De geinjecteerde code wordt uitgevoerd in de browser van het slachtoffer, waardoor de aanvaller sessies kan kapen, gevoelige gegevens kan stelen of acties kan uitvoeren namens de gebruiker. XSS behoort al jaren tot de meest voorkomende kwetsbaarheden in webapplicaties en staat prominent in de OWASP Top 10, de internationaal erkende lijst van kritieke webapplicatie-risico's die elke ontwikkelaar zou moeten kennen.

Het gevaar van cross-site scripting schuilt in de vertrouwensrelatie tussen een gebruiker en een website. Je browser vertrouwt de code die van een website komt en voert die zonder onderscheid uit. Als een aanvaller erin slaagt om kwaadaardige JavaScript in die website te injecteren, voert je browser die code uit alsof het legitiem is. Hierdoor kan de aanvaller cookies uitlezen, formuliergegevens onderscheppen, gebruikers omleiden naar phishing-pagina's of volledige controle over de sessie overnemen. De impact varieert van het stelen van inloggegevens tot het verspreiden van malware naar alle bezoekers van de getroffen website.

Hoe werkt cross-site scripting?

Er bestaan drie hoofdvormen van XSS die elk op een andere manier werken. Bij reflected XSS wordt de kwaadaardige code meegestuurd in een URL of formulier en direct teruggestuurd door de server in het antwoord. Een aanvaller stuurt bijvoorbeeld een link met een script in de zoekparameter naar het slachtoffer. Wanneer het slachtoffer op de link klikt, wordt het script uitgevoerd in de browser. Dit type komt veel voor bij zoekfuncties en foutmeldingen die gebruikersinvoer ongefiltreerd teruggeven. De aanvaller moet het slachtoffer verleiden om op de specifieke link te klikken, wat vaak via social engineering of phishing e-mails gebeurt.

Bij stored XSS wordt het kwaadaardige script permanent opgeslagen op de server, bijvoorbeeld in een database achter een webapplicatie. Dit gebeurt vaak via commentaarvelden, forumberichten, gebruikersprofielen of contactformulieren die invoer niet correct verwerken. Elke bezoeker die de pagina met het opgeslagen script bekijkt, wordt automatisch getroffen zonder verdere actie te ondernemen. Dit maakt stored XSS aanzienlijk gevaarlijker dan reflected XSS, omdat het slachtoffer geen speciale link hoeft te openen. Een enkel kwaadaardig bericht in een populair forum kan honderden of duizenden gebruikers treffen voordat het ontdekt en verwijderd wordt.

De derde variant is DOM-based XSS, waarbij de kwetsbaarheid volledig in de client-side JavaScript code zit. Het script manipuleert het Document Object Model van de pagina zonder dat de server bij de aanval betrokken is. Dit type is lastiger te detecteren omdat de kwaadaardige payload niet in serverlogboeken verschijnt en de server geen ongebruikelijk verkeer registreert. Aanvallers gebruiken deze techniek steeds vaker bij moderne single-page applicaties die veel client-side rendering en dynamische content gebruiken. De detectie vereist specifieke tooling die de client-side codeflow analyseert in plaats van alleen serverkant verkeer te monitoren.

Hoe herken je cross-site scripting?

XSS-aanvallen zijn lastig te herkennen voor eindgebruikers omdat de kwaadaardige code onzichtbaar in de achtergrond draait. Toch zijn er signalen waar je op kunt letten in je dagelijks gebruik van webapplicaties. Onverwachte pop-ups, omleidingen naar onbekende websites of vreemd gedrag op vertrouwde pagina's kunnen wijzen op XSS. Als je plotseling uitgelogd wordt, als formulieren zich anders gedragen dan gewoonlijk, of als je browser ongebruikelijke waarschuwingen toont, kan er sprake zijn van sessiediefstal via een XSS-aanval. Let ook op onverwachte URL-parameters met verdachte tekens als haakjes en aanhalingstekens.

Voor beheerders en ontwikkelaars zijn er betere detectiemethoden beschikbaar. Een web application firewall kan verdachte patronen in HTTP-verkeer herkennen en blokkeren voordat ze de applicatie bereiken. Geautomatiseerde securityscanners zoals OWASP ZAP en Burp Suite testen webapplicaties systematisch op XSS-kwetsbaarheden door het injecteren van testpayloads in alle invoervelden en URL-parameters. Content Security Policy headers helpen browsers te instrueren welke scripts uitgevoerd mogen worden en blokkeren inline scripts standaard, wat een effectieve verdedigingslaag vormt tegen geinjecteerde code.

Security monitoring op applicatieniveau, via een SIEM-oplossing, detecteert afwijkende patronen die op XSS-exploitatie kunnen wijzen. Denk aan een plotselinge toename van requests met verdachte payloads, ongebruikelijke cookie-activiteit of een hoog aantal sessiewisselingen. Door applicatielogboeken te koppelen aan netwerk- en identiteitsdata krijg je een compleet beeld van pogingen tot XSS-exploitatie en kun je snel ingrijpen om schade te beperken.

Hoe bescherm je je tegen cross-site scripting?

De belangrijkste bescherming tegen XSS is het correct verwerken van alle gebruikersinvoer in je webapplicaties. Dit betekent dat je invoer valideert, encodeert en onschadelijk maakt voordat het wordt weergegeven in de browser. Output encoding is daarbij cruciaal: je converteert speciale tekens zodat ze als tekst worden weergegeven in plaats van als uitvoerbare code. Dit geldt voor alle contexten: HTML-body, HTML-attributen, JavaScript, CSS en URL-parameters vereisen elk hun eigen encodingmethode om effectief te zijn.

Implementeer een strikt Content Security Policy. Dit HTTP-header instrueert de browser om alleen scripts uit vertrouwde bronnen uit te voeren en blokkeert alle inline scripts. Hierdoor worden geinjecteerde scripts geblokkeerd, ook als een aanvaller erin slaagt code in de pagina te krijgen. Gebruik daarnaast HttpOnly en Secure vlaggen op cookies om te voorkomen dat sessiecookies via JavaScript toegankelijk zijn. De SameSite-vlag biedt aanvullende bescherming tegen cross-site request forgery in combinatie met XSS-aanvallen.

Voer regelmatig penetratietesten uit op je webapplicaties om XSS-kwetsbaarheden te identificeren voordat aanvallers dat doen. Automatiseer securitytests in je development pipeline met tools voor static en dynamic application security testing. Train je ontwikkelaars in secure coding practices, zodat XSS-preventie standaard onderdeel wordt van het ontwikkelproces. Moderne frameworks zoals React, Angular en Vue bieden ingebouwde bescherming via automatische output encoding, maar custom code en onjuist gebruik van framework-functies blijven risicofactoren die aandacht vereisen bij code reviews.

Veelgestelde vragen over cross-site scripting

Wat is het verschil tussen reflected en stored XSS?

Bij reflected XSS wordt het kwaadaardige script via een URL of formulier direct teruggestuurd door de server. Het slachtoffer moet op een speciale link klikken. Bij stored XSS wordt het script opgeslagen in de database en treft het alle bezoekers van de pagina automatisch. Stored XSS is gevaarlijker omdat geen extra gebruikersinteractie nodig is.

Kan een firewall beschermen tegen XSS?

Een standaard netwerkfirewall beschermt niet tegen XSS. Een web application firewall kan verdachte patronen in HTTP-verkeer herkennen en blokkeren, maar is geen volledige oplossing. De effectiefste bescherming is secure coding: input validatie, output encoding en een strikt Content Security Policy vormen samen een geschikte verdediging.

Hoe test je je website op XSS-kwetsbaarheden?

Gebruik geautomatiseerde scanners zoals OWASP ZAP of Burp Suite om je webapplicatie systematisch te testen. Combineer dit met handmatige penetratietesten door een ervaren ethical hacker. Integreer SAST en DAST tools in je CI/CD pipeline voor continue beveiliging tijdens de ontwikkeling van nieuwe functionaliteit.

Is XSS nog steeds een relevant risico?

XSS blijft een van de meest voorkomende kwetsbaarheden in webapplicaties. Moderne frameworks bieden meer ingebouwde bescherming, maar onjuist gebruik, custom code en legacy applicaties blijven kwetsbaar. Het is een relevant risico zolang webapplicaties gebruikersinvoer verwerken en weergeven aan andere gebruikers.

Wat is DOM-based XSS?

DOM-based XSS is een variant waarbij de kwetsbaarheid volledig in client-side JavaScript zit. De aanval manipuleert het Document Object Model zonder betrokkenheid van de server. Dit maakt het lastiger te detecteren in serverlogboeken. Het komt steeds vaker voor bij single-page applicaties met uitgebreide client-side logica en dynamische rendering.

Bescherm je webapplicaties tegen XSS. Vergelijk Application Security Testing (AST) aanbieders op IBgidsNL.