Cross-Site Scripting (XSS)

Reflected XSS-aanvallen

Bij reflected XSS-aanvallen wordt het schadelijke script in een HTTP-verzoek geïnjecteerd (meestal via een specifiek aangepaste link die aan de gebruiker wordt doorgegeven). De eenvoudigste variant maakt gebruik van invoerparameters in het HTTP-verzoek die gemakkelijk kunnen worden gemanipuleerd om de schadelijke scriptinhoud op te nemen. Het schadelijke script wordt vervolgens gereflecteerd vanaf de server in een HTTP-respons en wordt uitgevoerd in de browser van het slachtoffer.

In dit geval werkt het als een opgeslagen XSS zonder daadwerkelijk schadelijke gegevens op de server op te slaan.

Hier volgt een voorbeeld van een gereflecteerde XSS-aanval:

Laten we zeggen dat example.com/profile een naamparameter bevat. De URL voor het verzoek zou er als volgt uitzien: https://example.com/profile?user=Tammy. Gebaseerd op deze invoer, zou de web applicatie dus reageren met “Hi Tammy” bovenaan de pagina. Als de parameters niet worden gevalideerd om er zeker van te zijn dat deze alleen verwachte gegevens bevatten, zou een aanvaller een gebruiker een kwaadaardige versie van de URL kunnen laten bezoeken, zoals deze: https://example.com/profile?user<script>some_malicious_code</script>.

Wanneer het antwoord naar de browser wordt gestuurd, bevat het dat schadelijke script, dat vervolgens in de browser wordt uitgevoerd, waarschijnlijk zonder dat de gebruiker dit zelfs maar weet. Dit is een voorbeeld van een gereflecteerde XSS-aanval, omdat de kwaadaardige code onmiddellijk wordt “gereflecteerd” naar de gebruiker die het verzoek doet.

Stored XSS Attacks

In wat bekend staat als een opgeslagen of persistente XSS-aanval, wordt kwaadaardige inhoud rechtstreeks afgeleverd, samen met het antwoord van de server wanneer de gebruiker een webpagina laadt. De inhoud is dus al opgeslagen in de database van de website (vandaar de naam voor dergelijke aanvallen). Gebruikers kunnen dan gewoon de gehackte webpagina openen en het slachtoffer worden van dergelijke aanvallen.

Elke gebruiker die zo’n gecompromitteerde website opent, loopt dus het risico dat zijn of haar persoonlijke gegevens worden gestolen, en daarom kan dit worden beschouwd als de gevaarlijkste soort XSS-aanval.

Maar hoe komt de kwaadaardige inhoud om te beginnen in de database terecht? In de meeste gevallen wordt de kwaadaardige inhoud binnengebracht via onbeveiligde webpaginaformulieren waarin de gebruikersinvoer niet goed wordt gevalideerd en gezuiverd. Als de door een hacker ingevoerde gegevens zowel aan de client- als aan de serverzijde niet worden gevalideerd, zullen ze in de database worden opgeslagen. Dergelijke invoer kan bijvoorbeeld plaatsvinden in een tekstgebied voor commentaar, een editor voor posttekst, een editor voor persoonlijke gegevens of andere formulieren.

Als een aanvaller er eenmaal in is geslaagd schadelijke inhoud naar de server te sturen en die inhoud ongefilterd op een webpagina verschijnt, worden alle gebruikers een potentieel slachtoffer.De gebruikelijke remedie voor opgeslagen XSS-aanvallen is het saniteren van invoer aan zowel de voor- als achterkant van de applicatie. Sanitizing bestaat uit een combinatie van het valideren van gegevens en het escapen van speciale tekens of het volledig uitfilteren daarvan en is een veelgebruikte best practice voor web- en JavaScript-beveiliging.

DOM-Based XSS Attacks

Document Object Model (DOM) is een interface waarmee toepassingen de structuur van een webpagina, de inhoud en de stijl ervan kunnen lezen en manipuleren. Bij een op het DOM gebaseerde XSS-aanval bevindt de kwetsbaarheid zich in de scriptcode aan de browserzijde en kan deze zonder enige interactie met de server worden misbruikt door de omgeving in de browser van het nietsvermoedende slachtoffer te wijzigen.

Soms lijken op het DOM gebaseerde XSS-aanvallen op gereflecteerde aanvallen. Het bovenstaande voorbeeld van een gereflecteerde XSS-aanval kan in dit geval met een enkele aanname worden toegepast: De webapplicatie leest gegevens rechtstreeks uit een querystring.

Laten we zeggen dat de applicatie de queryparameter “naam” gebruikt om direct de naam van de gebruiker op het scherm weer te geven terwijl hij wacht tot de rest van een pagina is geladen. Zonder de juiste validatie kan dit hetzelfde resultaat opleveren als bij een gereflecteerde aanval, als de hacker erin slaagt het slachtoffer een verdachte link te laten openen.

Zoals bij opgeslagen XSS moeten ontwikkelaars, om gereflecteerde en DOM-gebaseerde aanvallen te voorkomen, gegevensvalidatie implementeren en voorkomen dat ruwe gebruikersinvoer wordt weergegeven, ondanks de aan- of afwezigheid van communicatie met de server.

Wat zijn de vectoren voor Cross-site Scripting-aanvallen?

Er zijn verschillende vectoren die vaak bij XSS-aanvallen worden gebruikt:

• <script> tag: Een script-tag kan worden gebruikt om te verwijzen naar externe JavaScript-code, waardoor dit het meest eenvoudige XSS-punt is. Aanvallers kunnen de kwaadaardige code ook in de scripttag insluiten.
• JavaScript-events: Een andere populaire XSS-vector die door aanvallers wordt gebruikt, event-attributen, kunnen in een verscheidenheid aan tags worden toegepast. Voorbeelden hiervan zijn “onerror” en “onload”.
• <body> tag: Gebeurtenisattributen kunnen ook de bron van het script zijn wanneer ze worden aangeleverd via de “body”-tag.
• <img> tag: Afhankelijk van de gebruikte browser, kan dit attribuut door aanvallers worden gebruikt om de JavaScript-code uit te voeren.
• <iframe> tag: Vooral effectief voor phishing-aanvallen, deze vector maakt de XSS-aanval mogelijk om een andere HTML-pagina in te bedden in de huidige pagina.
• <input> tag: Sommige browsers staan manipulatie toe via deze vector, die kan worden gebruikt om een script in te sluiten.
• <link> tag: Deze tag kan een script bevatten, in plaats van het normale gebruik van linken naar externe stylesheets.
• <table> tag: Waar het achtergrondattribuut normaal verwijst naar een afbeelding, kan dit worden gecompromitteerd om te verwijzen naar het overtredende script.
• <div> tag: Deze tag bevat ook een achtergrondverwijzing en kan op dezelfde manier worden gebruikt als <table> om naar een script te verwijzen.
• <object> tag: Scripts van een externe site kunnen worden opgenomen met behulp van deze tag.

Hoewel er nog andere vectoren zijn die XSS-aanvallers gebruiken in hun pogingen om informatie te stelen en websites te compromitteren, zijn dit enkele van de meest gebruikte methoden. Ontwikkelaars moeten zich houden aan de juiste escaping- en sanitizing-praktijken om zich tegen dergelijke aanvallen te beschermen.

Afhankelijk van de aanvaller en zijn kwaadaardige bedoelingen, kunnen XSS-aanvallen verschillende gevolgen hebben, waaronder:

• het stelen van de sessie van een gebruiker, het gebruiken van inloggegevens om toegang te krijgen tot andere sites of de gebruiker omleiden naar onbedoelde websites,
• het wijzigen van websitepagina’s of het invoegen van delen in een webpagina,
• het uitvoeren van scripts om gevoelige informatie uit cookies of databases te extraheren,
• als het slachtoffer administratieve rechten heeft, kan de aanval zich uitbreiden naar de serverkant, waardoor verdere schade wordt aangericht of extra gevoelige informatie wordt achterhaald.

De belangrijkste stappen bij het testen van kritieke webapplicaties op XSS-kwetsbaarheden zijn onder meer:

• het gebruik van een code scantool om kwetsbaarheden op te sporen, zodat tijdens het ontwikkelingsproces correcties in de code kunnen worden aangebracht,
• het implementeren van geautomatiseerde testfunctionaliteit die potentiële kwetsbaarheden grondig en snel aan het licht brengt.

>