Wij zijn |
Cross-Site Scripting (XSS): wat is het en hoe te voorkomen
In de steeds veranderende wereld van cybersecurity is Cross-Site Scripting (XSS) uitgegroeid tot een van de meest bekende en meest voorkomende bedreigingen. Maar wat houdt een XSS-aanval precies in en hoe kun je je hier tegen verdedigen? In deze blogpost geven we uitleg over XSS-aanvallen, een complexe en vaak onderbelichte hackaanval die een serieuze impact kan hebben op zowel gebruikers als organisaties. We zullen de verschillende Cross-Site Scripting vormen bespreken, de technieken verkennen die worden gebruikt om ze uit te voeren maar ook hoe deze XSS-aanvallen voorkomen kunnen worden. Of u nu een webontwikkelaar, een IT-professional of gewoon iemand bent die meer wil leren over website security, deze blogpost biedt u waardevolle inzichten en praktische tips om uw webapplicatie te beschermen tegen XSS-kwetsbaarheden.
Cross-Site Scripting (XSS): wat is het en hoe te voorkomen
Wat is Cross-Site Scripting
Cross-Site Scripting (XSS) is een type kwetsbaarheid waarbij een kwaadwillende scriptcode in de webapplicatie kan injecteren. Deze scriptcode betreft vaak Javascript maar het kan ook HTML of Flash zijn. Het probleem wordt veroorzaakt doordat de gebruikersinvoer die de webapplicatie ontvangt niet juist wordt verwerkt. De browser van de eindgebruiker zal de scriptcode uitvoeren en daarmee kan een kwaadwillende de volledige controle krijgen over de webbrowser. Zo kan er bijvoorbeeld namens de eindgebruiker heimelijk acties worden uitgevoerd, gevoelige informatie zoals (onbeveiligde) sessietokens worden opgevraagd of de gehele webpagina worden herschreven. In onderstaande hoofdstukken worden de 3 vormen van Cross-Site Scripting behandeld.
Reflected Cross-Site Scripting (XSS)
Deze vorm van Cross-Site Scripting treedt op wanneer gebruikersinvoer onmiddellijk wordt verwerkt door de webapplicatie, bijvoorbeeld in een foutmelding of zoekresultaat. Hier wordt de invoer van de gebruiker direct weergegeven zonder deze te filteren op gevaarlijke gebruikersinvoer, wat leidt tot het uitvoeren van de scriptcode.
Ter demonstratie: in onderstaande voorbeeld is te zien dat de waarde van de parameter Name op de website wordt neergezet, dit wordt ook wel “gereflecteerd” genoemd.
De PHP-code achter dit voorbeeld ziet er als volgt uit:
In dit voorbeeld is te zien dat de inhoud van de parameter name wordt gepakt en zonder enige vorm van validatie via een echo terug wordt gezet op de webpagina. Tijdens een pentest beschikken we echter niet altijd over de broncode, bijvoorbeeld tijdens het uitvoeren van een blackbox pentest. Om XSS-kwetsbaarheden vast te stellen proberen we eerst altijd vast te stellen hoe de webapplicatie omgaat met HTML-code. In onderstaande voorbeeld is te zien dat <u>test</u> wordt ingevoerd en dat deze gebruikersinvoer als test wordt teruggegeven. Dit betekent dat de applicatie de HTML-code niet correct valideert en verwerkt.
Nadat is vastgesteld dat de webapplicatie vatbaar is voor een HTML-injectie is de volgende stap om vast te stellen hoe de applicatie omgaat met JavaScript-code. In onderstaande voorbeeld wordt de gebruikersinvoer: <script>alert()</script> ingevoerd. Het resultaat hiervan is dat een alertbox te zien is, dit betekent dat de JavaScript-code van de gebruikersinvoer door de browser uitgevoerd wordt en dat de applicatie dus vatbaar is voor XSS-aanvallen.
Stored Cross-Site Scripting (XSS)
Deze vorm is ook bekend als persistent Cross-Site Scripting (XSS) en vindt plaats wanneer gebruikersinvoer wordt opgeslagen op de server, bijvoorbeeld in een database. De scriptcode wordt later uitgevoerd wanneer een andere gebruiker de opgeslagen gegevens ophaalt. Hier kan bijvoorbeeld gedacht worden aan het plaatsen van een bericht op een forum. Als de webapplicatie deze invoer niet correct valideert en niet goed verwerkt, kan dit wederom leiden tot de uitvoer van scriptcode. Het verschil met reflected XSS is dat deze scriptcode opgeslagen staat op de website en dat er een grotere kans is dat een gebruiker bij normaal gebruik van de webapplicatie deze scriptcode uitvoert.
Om de werking van stored XSS te demonstreren, gebruiken we wederom het voorbeeld van de webapplicatie Damn Vulnerable Web Application (DVWA). In dit voorbeeld wordt de tekst <u>xxx</u> ingevoerd in het gastenboek. Nadat het plaatsen van dit bericht wordt de gebruikersinvoer opgeslagen in de onderliggende database en het bericht wordt bij het bezoeken van deze pagina vervolgens weergegeven. De applicatie verwerkt de gebruikersinvoer echter niet correct, zo is te zien dat de <u>-tag verwerkt is en de x’en onderstreept zijn.
Na dit vastgesteld te hebben wordt geprobeerd om Javascript-code op de pagina op te slaan. In onderstaande voorbeeld gebruiken we de scriptcode: <script>alert()</script> om aan te tonen dat ook de Javascript-code niet correct wordt gevalideerd en verwerkt en dat deze bij het bezoeken van de website wordt uitgevoerd. De webapplicatie is vatbaar voor Stored XSS-kwetsbaarheden.
DOM based Cross-Site Scripting (XSS)
DOM-based XSS (ook bekend als Type-0 XSS) is een vorm van XSS waarbij de kwetsbaarheid zich in de Document Object Model (DOM) van de webpagina bevindt. Dit type aanval treedt op wanneer scripts in de DOM worden gewijzigd door gebruikersinvoer zonder dat deze invoer goed wordt gevalideerd of verwerkt wordt door de webapplicatie. Het resultaat is wederom dat scritpcode wordt uitgevoerd binnen de context van de webpagina/website en dat aanvallers op deze manier bij gevoelige informatie zoals (onbeveiligde) cookies kunnen komen.
Om de werking van een DOM based XSS-aanval te demonstreren maken we wederom gebruik van de DVWA-applicatie. In onderstaande voorbeeld is te zien dat de gebruiker zijn of haar taal kan selecteren en dat deze keuze via de parameter default wordt vastgelegd.
Om een beter beeld te krijgen van de werking van deze webpagina wordt in onderstaande afbeelding de broncode (HTML) van de webpagina weergegeven. Hier is te zien dat met JavaScript de lang variabel wordt geïnitieerd met de waarde van de parameter “default”. Vervolgens wordt de waarde van deze variabel zonder enige validatie of verwerking gebruikt binnen de functie document.write. In het voorbeeld wordt dit uitgebuit door de code eerst af te sluiten en vervolgens en nieuw script-block te starten waarin een alert() wordt uitgevoerd.
"><script>alert()</script>
Ook dit zal leiden tot de uitvoer van de scriptcode, zoals in onderstaande afbeelding te zien is:
Wat is de impact van XSS
In bovenstaande voorbeelden tonen we de Cross-Site Scripting (XSS)-kwetsbaarheid steeds aan met een onschuldige alertbox. En misschien denk je, dit vormt toch geen risico voor mijn webapplicatie? Dat klopt, de alertbox vorm naast dat het mogelijk als vervelend ervaren kan worden, geen risico voor de gebruikers. Dit is echter een manier om aan te tonen dat het mogelijk is om Javascript-code uit te voeren in context van de webapplicatie. Dit betekent dat aanvallers de controle hebben over de volledige DOM (Document Object Model). Hiermee kan de aanvaller bijvoorbeeld alle gevoelige informatie die op de website staat inzien, actief namens de gebruiker uitvoeren, de sessietokens (cookies) stelen of zelfs de gehele HTML-code van de website herschrijven naar bijvoorbeeld een phishing login.
Er zijn veel bekende praktijkvoorbeelden van XSS-aanvallen die in het verleden hebben plaatsgevonden. Hier zijn enkele voorbeelden van de meest opvallende XSS-aanvallen:
MySpace (2005)
Een XSS-aanval op het sociale mediaplatform MySpace leidde tot de verspreiding van een worm genaamd “Samy“. De worm verspreidde zich snel en voegde gebruikers toe als vrienden, waardoor de profielpagina’s van slachtoffers werden gewijzigd waardoor de XSS-aanval steeds verder verspreid werd.
Twitter (2010)
Een XSS-aanval op Twitter leidde tot de verspreiding van een XSS-worm genaamd “Mikeyy“. De worm plaatste tweets op de getroffen accounts die links bevatten naar kwaadaardige websites.
Ebay (2015)
In de periode tussen eind 2015 en begin 2016, kampte eBay met een ernstige XSS-kwetsbaarheid. Deze kwetsbaarheid stelde aanvallers in staat om volledige toegang te krijgen tot eBay-verkopersaccounts, producten met korting te verkopen en betalingsgegevens te stelen. Het werd actief misbruikt door aanvallers om eBay-aanbiedingen van hoogwaardige producten, zoals voertuigen, te manipuleren.
Roudcube (2023)
Winter Vivern, een cyberespionagegroep gelinkt aan Rusland, maakte gebruik van een zero-day kwetsbaarheid in Roundcube‘s open source webmailservice om e-mails te stelen van Europese overheidsinstanties en denktanks. De XSS-aanval maakte het mogelijk om de inhoud van e-mails in te zien en gevoelige informatie te stelen.
Cross-Site Scripting-aanvallen voorkomen
Zoals in het vorige hoofdstuk vermeld zijn XSS-kwetsbaarheden een serieuze bedreiging voor webapplicaties, maar er zijn stappen die je kunt nemen om ze te voorkomen en te verhelpen. Hier bespreken we enkele belangrijke maatregelen om je webapplicatie te beschermen tegen XSS-aanvallen.
Filter gebruikersinvoer
Het begint allemaal bij het ontvangen van gebruikersinvoer. Hier moet je zeer strikte filtering toepassen op basis van wat wordt verwacht qua geldige invoer. Dit betekent dat je nooit gebruikersinvoer moet vertrouwen en deze nooit ongefilterd in de webapplicatie moet verwerken. Filters moeten speciale tekens (zoals “, ‘, < en >) omzetten in hun HTML-gecodeerde equivalenten om te voorkomen dat kwaadwillende scripts worden uitgevoerd.
Daarnaast is het mogelijk om te filteren en valideren op inhoudelijke aspecten. Bijvoorbeeld, een telefoonnummer zou alleen cijfers en mogelijk een plusteken moeten bevatten, terwijl een (voor)naam nooit tekens zoals groter (>) of kleiner dan (<) zou mogen bevatten. Hierdoor kun je controleren of de ingevoerde gegevens zinvol en veilig zijn voor verdere verwerking.
Codeer gegevens bij uitvoer
Een andere manier om XSS-aanvallen te voorkomen is door de gebruikersinvoer te encoderen bij het weergeven in de webapplicatie. Dit kan bijvoorbeeld door gebruik te maken van HTML-entities of andere relevante coderingen toe te passen. Hierdoor wordt voorkomen dat de gebruikersinvoer wordt geïnterpreteerd als HTML-elementen in de webpagina. Een voorbeeld van gevaarlijke karakters en de HTML-entiteit gecodeerde tegenhangers:
- & &
- < <
- > >
- ” "
- ‘ '
Beveiligingsmaatregelen van moderne webbrowsers
Als extra beveiligingslaag kun je een Content Security Policy (CSP) implementeren. CSP is een browserfunctie waarmee je bepaalt welke bronnen of scripts uitgevoerd mogen worden. Hiermee kun je de impact van eventuele XSS-kwetsbaarheden verminderen of zelfs voorkomen door het beperken van de uitvoering van onbekende scripts of inline scripts (unsafe-inline).
Naast CSP zijn er al veel ingebouwde beveiligingsmaatregelen in moderne browsers en applicaties om XSS-aanvallen te voorkomen. Maar zelfs met deze maatregelen in plaats, blijft het belangrijk om op de hoogte te zijn van de gevaren die XSS met zich meebrengt. Het is belangrijk om maatregelen te nemen en te blijven investeren in webbeveiliging om je webapplicatie te beschermen tegen XSS-aanvallen.
Voor meer informatie over XSS en het verhelpen daarvan verwijzen we naar de OWASP-cheatsheet.
Hoe Pentests.nl u kan helpen?
Bij Pentests.nl zijn we gespecialiseerd in het uitvoeren van pentesten. Onze ervaren pentesters hebben de kennis en vaardigheden om uw webapplicaties grondig te testen op bijvoorbeeld Cross-Site Scripting (XSS)-kwetsbaarheden en andere webgerelateerde kwetsbaarheden. We zijn een actief lid van de branchevereniging Cyberveilig Nederland, en we onderscheiden ons door onze jarenlange ervaring en expertise in het uitvoeren van pentesten.
Bent u klaar om de beveiliging van uw websites te versterken en hackers één stap voor te zijn? Neem dan vrijblijvend contact met ons op om de mogelijkheden te bespreken. Ons team van experts staat klaar om u te helpen bij het navigeren door de complexiteit van XSS-kwetsbaarheden en het versterken van uw algehele weerbaarheidsniveau.
Hoe kunnen wij u helpen?
QR Codes: Het onverwachte wapen in Device Code Phishing
Device code phishing, net als aanvallen via Adversary-in-the-middle (AiTM), vertegenwoordigt een geavanceerde vorm van cyberdreiging die zich onderscheidt van traditionele phishing. Device code phishing exploiteert de ‘OAuth2 Device Authorization Grant flow‘ van Microsoft Azure, die gebruikers in staat stelt zich aan te melden bij apparaten met beperkte invoermogelijkheden.
CORS: het belang van Cross-Origin Resource Sharing
Bij onze klanten zien we een toenemende implementatie van Cross-Origin Resource Sharing (CORS). Helaas constateren we ook een stijging in het aantal onveilig geconfigureerde CORS-implementaties. In deze blog duiken we dieper in wat CORS is, de meest voorkomende misconfiguraties en hun potentiële risico’s, en hoe je sterke CORS-regels kunt instellen om je webapplicaties te beschermen.
Security headers: het wat en waarom
In deze blogpost lees je het hoe en waarom van de Content Security Policy (CSP). Met deze HTTP security header kan je de webbrowser van gebruikers fijnmazige instructies geven die bescherming bieden tegen hackaanvallen.