Wat is XSS?

Cross-site scripting of XSS is een kwetsbaarheid die typisch voorkomt in webapplicaties. Het is een type injectie waarmee een aanvaller kwaadaardige scripts kan uitvoeren op de machine van een slachtoffer. Wanneer er geen beveiligingsmaatregelen worden genomen, heeft de browser geen manier om te weten dat het script niet vertrouwd moet worden. Op deze manier kan de aanvaller toegang krijgen tot gevoelige informatie waarvoor de browser toegang heeft. 

Er zijn verschillende soorten XSS en elke soort heeft een andere impact. Laten we ze één voor één bekijken:

Bewaar XSS

Bewaar XSS, ook bekend als persistente XSS, is een type XSS waarbij het kwaadaardige script op de doelserver is opgeslagen. Nadat het script op een server is opgeslagen, hoeft de aanvaller alleen maar te wachten tot slachtoffers de webpagina met het kwaadaardige script op deze server bekijken. Zodra een slachtoffer deze pagina bekijkt, wordt het kwaadaardige script in hun browser uitgevoerd. 

Bewaar XSS is een gevaarlijk type XSS, omdat veel slachtoffers met een enkele payload kunnen worden aangevallen. De slachtoffers hoeven geen extra stappen te nemen behalve toegang te krijgen tot een normaal vertrouwde website.

Bewaar XSS

Reflected XSS

Reflected XSS is wanneer de kwaadaardige payload deel uitmaakt van het verzoek aan een website. Het slachtoffer moet op een link klikken om deze aanval succesvol te laten zijn. Een aanvaller kan proberen een slachtoffer te misleiden om op een link te klikken via e-mail of een ander soort bericht. Nadat het slachtoffer deze website via de kwaadaardige link heeft bekeken, omvat de website deze payload in de reactie terug naar het slachtoffer.

Reflected XSS

DOM-gebaseerde XSS

Een DOM-gebaseerde XSS-kwetsbaarheid bestaat wanneer JavaScript gegevens van een aanvaller neemt en deze doorgeeft aan een sink. Het Document Object Model, of DOM, is een interface waarmee JavaScript kan communiceren met de HTML van een webpagina. Een sink is een JavaScript-functie of een DOM-object dat een kwaadaardig script kan uitvoeren tijdens een XSS-aanval. DOM-gebaseerde XSS is zoals reflected XSS, dat doorgaans wordt bereikt door een slachtoffer te misleiden om op een link te klikken. 

Het verschil tussen deze typen aanvallen is dat bij reflected XSS de payload op de reactiepagina wordt geplaatst en bij DOM-gebaseerde XSS dit gebeurt in de client-side code die in de pagina is opgenomen.

Zelf XSS

Tijdens een zelf XSS-aanval wordt het slachtoffer gemanipuleerd om kwaadaardige code in hun webbrowser uit te voeren. De aanvaller stuurt kwaadaardige code naar het slachtoffer, die deze code moet plakken in de browser om deze uit te voeren. Voor dit type XSS om succesvol te zijn, moet het slachtoffer meerdere stappen volgen die door de aanvaller worden verstrekt. 

Zelf XSS

In de context van bug bounty wordt Zelf XSS vaak ook gebruikt om te verwijzen naar XSS-kwetsbaarheden die bestaan op een plek waar alleen de aanvaller zelf ze kan activeren, waardoor het onmogelijk wordt om andere gebruikers te beïnvloeden en een effectieve aanval uit te voeren. Vanwege deze bijna nul impact wordt dit type kwetsbaarheid vaak afgewezen.

Impact

Wanneer een XSS-aanval succesvol is, kan het slachtoffer volledig gecompromitteerd zijn. De aanvaller zal vaak enkele van de volgende proberen:

• Sessiecookies stelen. Met de sessiecookies kan de aanvaller zich voordoen als het slachtoffer en toegang krijgen tot zijn informatie.

• Inloggegevens stelen. 

• Toegang krijgen tot gevoelige informatie.

De impact van de verschillende types XSS kan vergelijkbaar zijn met elkaar als ze succesvol zijn. Bewaar XSS wordt beschouwd als het gevaarlijkste type XSS, omdat het veel gebruikers beïnvloedt. Ook is gebruikersinteractie noodzakelijk voor de andere soorten XSS om succesvol te zijn. Deze extra interactie maakt reflected en DOM-gebaseerde aanvallen minder ernstig.

XSS voorkomen

Er zijn een paar dingen die gedaan kunnen worden om te voorkomen dat XSS optreedt op een website.
Filter invoer:

• Als een gebruiker een URL indient die in reacties zal worden geretourneerd, valideer dan dat deze begint met een veilige protocol zoals HTTPS.

• Valideer dat de invoer alleen een verwachte set van karakters bevat. 

• Maak een lijst van veilige invoer en sta niets toe dat niet op deze lijst staat.

• Codeer gegevens bij uitvoer, bijvoorbeeld door de invoergegevens te URL-encoderen wanneer deze worden weergegeven om te voorkomen dat deze door de browser of toepassing als uitvoerbare inhoud wordt geïnterpreteerd.

Impact mitigeren

Cookie-vlaggen
De httponly- en secure-vlaggen kunnen worden gebruikt om sessiecookies te beschermen tegen XSS.

XSS-aanvallen zijn vaak gericht op het stelen van sessiecookies om toegang te krijgen tot de informatie van een slachtoffer. Als de sessiecookie is ingesteld met een httponly-vlag, is deze beschermd tegen toegang met JavaScript.

De secure-vlag wordt gebruikt om ervoor te zorgen dat de cookie alleen kan worden verzonden via een veilige verbinding zoals https. De browser zal de cookie nooit verzenden met gewone HTTP.

Content Security Policy
De content security policy, of CSP, is een HTTP-respons-header die helpt bepaalde aanvallen, waaronder XSS, te detecteren en te mitigeren. CSP maakt het mogelijk om te beperken hoe middelen zoals JavaScript of iets anders dat de browser laadt. De CSP kan ook aanvallen verminderen door de domeinen op te geven die als vertrouwde bronnen moeten worden beschouwd. De browser zal alleen deze vertrouwde scripts uitvoeren en alle andere scripts negeren.

We hopen dat je genoten hebt van onze blog over XSS! Blijf op de hoogte voor onze volgende blog over de kwetsbaarheid Insecure Direct Object Reference (IDOR)!

Meer informatie

• Een spiekbriefje met voorbeelden van code die je kunt gebruiken tijdens het testen op XSS.

• Informatie over de content security policy met voorbeelden van hoe deze te gebruiken