We leven in een tijdperk van snelle digitale transformatie met innovatieve oplossingen waarmee we een breed scala aan taken sneller en gemakkelijker kunnen uitvoeren. Nu technologieën zich blijven ontwikkelen, creëren hackers en bedreigingsactoren geavanceerde tegenmaatregelen door deze futuristische technologieën te misbruiken.
Hoewel beveiligingsprofessionals constant werken aan het ontwikkelen van praktische cybersecuritytools, worden websitegebruikers blootgesteld aan nieuwe kwetsbaarheden – met cross-site scripting (XSS) als een van de meest voorkomende cyberdreigingen.
Wat is Cross-Site Scripting (XSS)?
Cross-site scripting (XSS) is een beveiligingsaanval met code-injectie, die een bedreigingsactor in staat stelt kwaadaardige scripts in te voegen in webbrowsers van vertrouwde webapplicaties of websites. In tegenstelling tot SQL injection en andere aanvalsvectoren die rechtstreeks toegang krijgen tot de database, richt XSS zich op de eindgebruiker om volledige controle over de operaties te verkrijgen.
Door zich voor te doen als gebruikers, kan de kwaadwillende actor de actieve sessiecookie van de gebruiker stelen en toegang krijgen tot hun vertrouwelijke gegevens. De browser van het slachtoffer kan legitieme markup niet onderscheiden van kwaadaardige markup en voert deze uit.
XSS staat op de achtste plaats in de lijst van de OWASP Top 10 meest kritieke kwetsbaarheden in webapplicaties. De rankings van de Open Web Application Security Project worden verstrekt door beveiligingsexperts van over de hele wereld om ontwikkelaars te helpen zwakheden in het systeem te beveiligen en de aanwezigheid van bekende risico’s te verminderen.
Wat zijn de soorten XSS-aanvallen?
Afhankelijk van waar een hacker kwaadaardige input invoert, kan XSS worden onderverdeeld in drie hoofdcategorieën:
Opgeslagen Cross-Site Scripting
Opgeslagen XSS of Persistent XSS is het gevaarlijkste type XSS-aanval, dat veel bezoekers kan compromitteren en tot verwoestende gevolgen kan leiden. Opgeslagen XSS ontstaat wanneer de input van de gebruiker niet wordt gevalideerd voordat inhoud wordt opgeslagen en weergegeven op de webpagina.
Sociale netwerken, forums, blogwebsites, gebruikersprofielen, prikborden en commentaarsecties zijn veelvoorkomende gebieden waar XSS kan worden opgeslagen. Bedreigingsactoren maken misbruik van deze kwetsbaarheid door XSS-payloads te injecteren op de meest bezochte websitepagina’s. Bij het klikken op de gecreëerde link en het openen van de virale pagina, voert de webbrowser van het slachtoffer de payload aan de clientzijde uit.
Hieronder een duidelijke illustratie van een opgeslagen XSS-kwetsbaarheid. Een gebruiker kan berichten achterlaten op een prikbordapplicatie, die andere gebruikers kunnen bekijken:
<p>Hello, this is my message!</p>De applicatie verwerkt de gegevens niet verder, waardoor het voor een fraudeur eenvoudig is om een bericht te sturen dat andere gebruikers target:
<p><script>/* Bad stuff here... */</script></p>Gereflecteerde Cross-Site Scripting
Gereflecteerde XSS is de meest gebruikte cross-site scripting-aanval (ook bekend als non-persistent XSS). Tijdens deze aanval voegt een hacker kwaadaardige code toe aan het einde van de URL. Zodra de gebruiker op deze link klikt in hun webbrowser, voert de browser de gereflecteerde XSS-payload uit.
De bedreigingsactor gebruikt doorgaans kwaadaardige URL’s, phishing-e-mails en andere digitale social engineering-aanvallen om het slachtoffer te misleiden om op de link te klikken. Doorgaans worden de volgende XSS-aanvallen uitgevoerd met behulp van sociale netwerken.
Om de gereflecteerde XSS-kwetsbaarheid te illustreren, bekijk het onderstaande voorbeeld:
https://insecure-website.com/status?message=All+is+well.
<p>Status: All is well.</p>De webapplicatie voert geen aanvullende gegevensverwerking uit, waardoor een hacker de volgende aanval kan uitvoeren:
https://insecure-website.com/status?message=
<p>Status: <script>/* Bad stuff here... */</script></p>DOM-gebaseerde Cross-Site Scripting
Overtreders kunnen kwaadaardige code op een pagina invoegen door de DOM-omgeving (Document Object Model) te wijzigen wanneer deze de invoer van de gebruiker niet correct filtert. De HTML-broncode en respons van de aanval zijn identiek bij DOM-gebaseerde XSS. De pagina zelf blijft hetzelfde, maar door de kwaadaardige wijzigingen aan de DOM-omgeving, wordt de client-side code op de pagina onverwacht uitgevoerd.
DOM-gebaseerde XSS is volledig een client-side injectiekwetsbaarheid. Daarom bereikt de parasitaire payload nooit de server. Vanwege de unieke aard van DOM-gebaseerde XSS is het voor Web Application Firewalls (WAF’s) en andere beveiligingstools voor webapplicaties moeilijk om de aanvallen te detecteren.
De webapplicatie in het onderstaande voorbeeld gebruikt JavaScript om de waarde uit een invoerveld te lezen en die waarde in een element binnen de HTML te schrijven:
var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;Als de bedreigingsactor controle heeft over de waarde van het invoerveld, kunnen ze gemakkelijk een kwaadaardige waarde creëren die hun script op een onveilige manier laat handelen:
You searched for: <img src=1 onerror='/* Bad stuff here... */'>Hoe kan een bedreigingsactor XSS exploiteren?
Doorgaans heeft de kwaadaardige inhoud die naar de webbrowser wordt gestuurd de vorm van een JavaScript-segment, maar het kan ook HTML, Flash, VBScript, ActiveX of enige andere code bevatten die de browser kan uitvoeren.
Op JavaScript gebaseerde XSS-aanvallen zijn het meest wijdverbreid, aangezien JavaScript een fundamenteel onderdeel is van de meeste browse-ervaringen.
JavaScript kan cookies in de browser lezen, waardoor de aanvaller een XSS-aanval kan uitvoeren en zich kan voordoen als de gebruiker voor identiteitsdiefstal en andere snode activiteiten. JavaScript biedt verschillende modules en methoden om HTTP-verzoeken te maken, die kunnen worden gebruikt om gegevens (zoals gestolen cookies) terug te sturen naar de bedreigingsactor. Bovendien kan de kwetsbaarheid van client-side JavaScript voor hacken fraudeurs helpen toegang te krijgen tot API’s en eenvoudig de geografische locatie, webcamgegevens en andere privé-informatie van klanten compromitteren.
Door XSS-kwetsbaarheden te benutten, kan een bedreigingsactor kwaadaardige activiteiten uitvoeren, zoals:
- De sessie van de gebruiker kapen. Sessiekaping is een methode om de geauthenticeerde sessie van een gebruiker over te nemen. Sessiecookies bevatten kritieke gegevens waarmee een bedreigingsactor zich kan voordoen als een legitieme gebruiker en de sessie-ID kan verkrijgen als deze is gecompromitteerd.
- Ongeautoriseerde acties uitvoeren. Aanvallers kunnen de cookies niet stelen via JavaScript als het HTTPOnly cookie-attribuut is ingesteld. Maar door de XSS-aanval uit te voeren, kunnen ze nog steeds ongeautoriseerde activiteiten binnen de applicatie namens het slachtoffer uitvoeren.
- Phishingaanvallen uitvoeren. Phishing is een veelvoorkomend type cyberaanval waarbij de aanvaller een formulier injecteert op de kwetsbare pagina en dat gewijzigde formulier gebruikt om de inloggegevens van de gebruiker te stelen, meestal in de vorm van wachtwoorden, bankrekeninginformatie en creditcardnummers.
- Toetsaanslagen van gebruikers vastleggen. Dit is waarbij een hacker een JavaScript keylogger in de kwetsbare pagina invoegt en de toetsaanslagen van het slachtoffer op de huidige webpagina bewaakt. De verzamelde informatie kan gebruikersnamen, wachtwoorden en potentieel compromitterende gegevens onthullen die hackers voor financieel gewin kunnen gebruiken.
- Gevoelige informatie stelen. Door een XSS-aanval uit te voeren, verzamelt een aanvaller gegevens uit de huidige sessie van de gebruiker. Cross-site scripting-aanvallen op online bankapplicaties kunnen bijvoorbeeld aanvallers toestaan het huidige saldo, transactiegegevens, persoonlijke informatie, enz. te bekijken.
XSS-kwetsbaarheden bevorderen de escalatie van aanvallen naar een ernstiger niveau en, indien misbruikt door fraudeurs, kunnen ze ernstige schade veroorzaken. XSS-aanvallen kunnen leiden tot blootstelling van gevoelige gegevens, compromittering van het account van het slachtoffer en erger.
Door een nepformulier te maken, lokken aanvallers webgebruikers ertoe hun inloggegevens te verstrekken, waardoor ze alle informatie over de gebruiker kunnen verkrijgen. Zodra de slinkse bedoeling van de hackers om hun slachtoffers te misleiden is vervuld, kunnen de verkregen gegevens worden gebruikt voor identiteitsdiefstal of financiële fraude.
Real-life XSS-voorbeelden
Cross-site scripting-aanvallen hebben bekende bedrijven veel schade kunnen berokkenen. Hieronder de beroemdste voorbeelden:
Fortnite
Fortnite is een gamefenomeen – een van de populairste online battle games met meer dan 200 miljoen spelers wereldwijd. Vanwege de enorme populariteit werd het spelplatform het hoofddoelwit voor kwaadwillende actoren en kon het begin 2019 te maken krijgen met een XSS-aanval die leidde tot datalekken.
Beveiligingsonderzoekers van Check Point Software Technologies ontdekten de cross-site scripting-kwetsbaarheid in de game, die hackers in staat had kunnen stellen om gamersaccounts over te nemen, toegang te krijgen tot hun gevoelige informatie, virtuele valuta binnen het spel te stelen en hun gesprekken af te luisteren. De experts hebben de geïdentificeerde XSS-kwetsbaarheden privé gemeld aan de gameontwikkelaar Epic Games, en het bedrijf heeft de problemen verholpen.
British Airways
In 2018 werd British Airways geconfronteerd met een datalek dat 380.000 boektransacties trof. De onderzoekers van RiskIQ wisten Magecart te onderscheppen – een van de grootste hackergroepen die berucht is om het gebruik van online skimmingtechnieken. De hackers vielen de website van British Airways aan door misbruik te maken van een XSS-kwetsbaarheid in een JavaScript-bibliotheek genaamd Feedify.
Nadat ze het script hadden gewijzigd, stuurden de daders klantgegevens naar hun aangewezen server met een domeinnaam die vergelijkbaar was met British Airways en slaagden ze erin creditcardgegevens te skimmen. De kwaadaardige server had een SSL-certificaat, dus klanten vertrouwden volledig op de server waarvan ze kochten.
eBay
eBay is een van de vroegste en populairste e-commerceplatforms. Het werd echter eind 2014 en begin 2015 gecompromitteerd via een cross-site scripting-kwetsbaarheid. De website gebruikte een URL-parameter die eBay-leden naar verschillende pagina’s omleidde, maar de waarde van de parameter werd niet gecontroleerd voordat deze in de pagina werd opgenomen. Vanwege deze fout konden aanvallers een URL maken met daarin een parasitaire iFrame en deze injecteren in de legitieme eBay-website.
Zo konden fraudeurs toegang krijgen tot eBay-verkopersaccounts, betaalgegevens stelen, producten met korting verkopen en eBay-aanbiedingen van waardevolle producten zoals voertuigen manipuleren. Hoewel eBay het probleem vervolgens heeft verholpen, gingen terugkerende aanvallen door tot 2017.
In 2011 werden er binnen 10 dagen drie afzonderlijke XSS-kwetsbaarheden op Facebook-sites gedetecteerd. Minstens twee werden gebruikt om virale links en aanvallen op Facebook-gebruikers te verspreiden om toegang te krijgen tot informatie op hun accounts of deze te wijzigen.
Vanwege onvoldoende JavaScript-filtering kwam het eerste probleem via een pagina op de mobiele API-versie van Facebook. De interface drong ertoe aan dat mensen een willekeurig bericht op hun tijdlijn plaatsten. Bovendien werd een tweede XSS-kwetsbaarheid ontwikkeld met behulp van HTML binnen een virale pagina om malware over de website te verspreiden. Verschillende links verspreidden snel phishingaanvallen, die de aandacht trokken van beveiligingsonderzoekers, en Facebook slaagde erin de XSS-kwetsbaarheid te patchen.
Het laatste XSS-probleem dat aan het licht kwam, betrof een Facebook- “channel”-pagina voor sessiebeheer, waarbij een code-update per ongeluk het gedrag van de pagina wijzigde. Zodra beveiligingsexperts dit echter opmerkten, heeft Facebook de fout onmiddellijk hersteld.
Cross-site scriptingkwetsbaarheden detecteren
De redenen voor het optreden van XSS-kwetsbaarheden zijn:
- Invoervalidatie wordt niet uitgevoerd.
- Uitvoer naar de browser wordt niet geconverteerd naar HTML-tekentekens.
Over het algemeen worden webscannertools gebruikt om te zoeken naar beveiligingskwetsbaarheden in webapplicaties. Deze geautomatiseerde tools injecteren kwaadaardige scripts in de webapplicatie, zoals GET- of POST-variabelen, URL’s, cookies en andere code die XSS-aanvallen kan uitvoeren. Als de tool erin slaagt het script in de webpagina te injecteren, is de site blootgesteld aan XSS. Na het ontdekken van malware-aanvalsvectoren, meldt de tool de gebruiker van de gedetecteerde kwetsbaarheid.
XSS-preventie en -mitigatie
Cross-site scripting (XSS) kan een ernstige bedreiging vormen voor individuele gebruikers en bedrijven wiens websites geïnfecteerd kunnen raken. In sommige gevallen is het moeilijk om de aanval af te weren. Om deze reden moet u alle onbetrouwbare gegevens grondig opschonen om uzelf te beschermen tegen XSS. Om het risico voor uw webapplicatie te verkleinen, mag uw browser gegevens die als invoer worden ontvangen nooit verwerken zonder deze te valideren.
Specifieke preventiemethoden variëren afhankelijk van de subtype XSS-kwetsbaarheid en de context van het gebruik van gebruikersinvoer. Er moeten echter bepaalde algemene maatregelen worden genomen om uw gebruikers te beschermen tegen XSS-aanvallen en uw webapplicatie veilig te houden:
Validatie
Hier zorgt u ervoor dat invoer veilig is voor verwerking binnen de code en dat misvormde gegevens geen schade toebrengen aan een website, database en gebruikers. Door verzoeken van externe partijen of bronnen af te wijzen, voorkomt invoer validatie dat gebruikers speciale tekens invoeren in gegevensinvoervelden op de websites. Invoer validatie ontmoedigt injectieaanvallen, datalekken en gecompromitteerde systemen.
Codering
Codering is een essentiële verdedigingslinie tegen XSS. Hier, op het punt waar door de gebruiker controleerbare gegevens worden uitgevoerd in HTTP-antwoorden, codeert u de uitvoer zodat de browser deze alleen als gegevens interpreteert, niet als uitvoerbare code. Verschillende coderingsmethoden kunnen nodig zijn, afhankelijk van de uitvoercontext, aangezien browsers JavaScript, JS, URL, HTML en CSS anders analyseren.
Instellen van HttpOnly-vlaggen
De volgende voorzorgsmaatregel helpt XSS-aanvallen te mitigeren. Als deze extra vlag is opgenomen in de HTTP-antwoordheader, kan de cookie met de vertrouwelijke informatie van de gebruiker niet worden benaderd via het client-script. Gebruik het HttpOnly-attribuut om te voorkomen dat JavaScript de gevoelige inhoud van de cookie leest, waardoor het voor een hacker moeilijk wordt om de sessie te kapen en het account over te nemen.
Content Security Policy
Content Security Policy (CSP) is een extra beveiligingslaag die is ontworpen om de ernst van eventuele XSS-kwetsbaarheden te verminderen. Dit browserbeveiligingstool helpt XSS en andere client-side aanvallen af te weren en te mitigeren.
Regelmatig scannen
U moet een robuuste webkwetsbaarheidsscanner uitvoeren op uw webservers om te voorkomen dat kwaadaardige inhoud wordt uitgevoerd door onoplettende gebruikers of bezoekers. Pentesters en beveiligingsexperts gebruiken regelmatig XSS-scantools voor analyse van webapplicaties.
Penetratietesten
Penetratietesten is een cyberbeveiligingstechniek die het perspectief van een hacker gebruikt om zwakke plekken in systemen te vinden en cyberbeveiligingsrisico’s te mitigeren, waardoor organisaties de geïdentificeerde mazen kunnen dichten voordat kwaadwillende hackers ze bereiken.
Kwantiteitsscans zijn geen vervanging voor penetratietesten. Pentesters imiteren de benaderingen van echte dreigingsactoren en concentreren zich op beveiligingskwetsbaarheden die niet automatisch kunnen worden geïdentificeerd.
Het QAwerk-team bestaat uit professionele pentesters die goed overweg kunnen met geavanceerde tools om grondige beveiligingsaudits en kwetsbaarheidsanalyses uit te voeren.
Hoe XSS-fouten effectief te verhelpen?
U kunt verschillende maatregelen nemen om uw website te herstellen als cross-site scripting optreedt:
- Vind kwetsbare code. In de eerste fase van herstel van cross-site scripting identificeert u de locatie van de kwetsbaarheid.
- Verwijder kwaadaardige inhoud en backdoors. Zodra u weet waar de malware zich bevindt, kunt u alle kwaadaardige inhoud of onjuiste gegevens uit uw database verwijderen en deze herstellen naar een schone staat met een robuuste tool voor het verwijderen van website-malware. Bovendien moet u de rest van uw website en bestandssystemen scannen op backdoors om bestaande fouten te corrigeren en de reputatie van uw website te handhaven.
- Patch de kwetsbaarheid. Daders maken vaak misbruik van zwakke plekken in databases, apps en componenten van derden. Als deze een reëel risico vormen, moeten ze worden gepatcht. Nadat u de kwetsbare software hebt geïdentificeerd, verspreidt en past u updates toe op de kwetsbare code om kwetsbaarheden te verwijderen die zijn gemarkeerd.
- Wijzig uw inloggegevens. In geval van XSS is het cruciaal om onmiddellijk uw wachtwoorden en applicatiegeheimen opnieuw in te stellen met een sterk wachtwoordbeleid zodra de kwetsbaarheid is gepatcht. Zorg ervoor dat er geen backdoors of ongeldige beheerdersaccounts in de database staan door uw gegevens op te schonen om herinfectie te voorkomen.
- Stel een WAF in. Een belangrijk onderdeel van uw beveiligingsstrategie is het instellen van een krachtige webapplicatiefirewall (WAF) om specifiek XSS aan te pakken door kwaadaardige serververzoeken naar uw website te blokkeren die gericht zijn op het exfiltreren van gevoelige gegevens. Met een geschikte WAF kunt u zich beschermen tegen potentiële bedreigingen voordat patches beschikbaar zijn.
Conclusie
Cross-site scriptingaanvallen maken misbruik van beveiligingslekken op het web door een dreigingsacteur toe te staan client-side beveiligingsmechanismen te omzeilen en kwaadaardige JavaScript-code te injecteren in verder onschadelijke websites. Op basis van de functionaliteit en de verwerkte gegevens door de kwetsbare applicatie, kunnen XSS-kwetsbaarheden een aanzienlijke bedreiging vormen voor bedrijven. Door zich voor te doen als een betrouwbare bron met een aantrekkelijke aanvraag, kunnen hackers de accounts van gebruikers imiteren, hun gedrag observeren, externe inhoud laden en de gehele websessies van de slachtoffergebruikers overnemen.
Daarom is het cruciaal om te begrijpen waar uw systeem tekortkomingen heeft en preventieve maatregelen te nemen voordat een XSS-aanval de website en zijn bezoekers ernstig schaadt. Tenzij de variabelen in een webapplicatie een validatieproces doorlopen, zijn ze een potentiële kwetsbaarheid. De meest effectieve beschermingsbenaderingen om XSS-aanvallen af te weren zijn: gegevens opschonen, cookies beveiligen, HTML-tags uit strings verwijderen, kwetsbaarheden scannen en regelmatige penetratietesten door professionals.
Verbeter nu de beveiliging van uw web-app: De ultieme XSS-cheat sheet
