Cross-site scripting (XSS) is een aanval waarbij iemand een schadelijk script op jouw pagina zet dat meedraait in de browser van je bezoekers. Bezoekers vertrouwen de pagina omdat hij van jou komt, dus de schade raakt hen en je reputatie. De oorzaak zit in code die invoer niet goed controleert.
Wat is cross-site scripting?
De pagina zelf komt van jouw site, dus de browser vertrouwt het script alsof jij het erin hebt gezet. Dat maakt de aanval gevaarlijk: de schade komt terecht bij je bezoekers en je reputatie, en niet alleen bij je server.
XSS ontstaat als een site tekst van iemand anders op een pagina toont zonder die als gewone tekst te behandelen. Een reactie, een profielnaam, een zoekterm in het adres of een formulierveld kan op een pagina belanden. Bevat de tekst scriptcode en toont de site hem als code, dan voert elke browser die de pagina laadt hem uit.
Er zijn drie gangbare soorten. Stored XSS slaat het script op de site op, bijvoorbeeld in een reactie, zodat iedereen die die reactie ziet erdoor geraakt wordt. Reflected XSS zit in een link: het script draait alleen bij mensen die op die link klikken. DOM-based XSS zit in het eigen script van de pagina, dat in de browser onveilig met invoer omgaat.
Wat een script kan doen
Een script op jouw pagina draait met de rechten van de bezoeker op jouw site. Het kan veranderen wat de pagina toont, de bezoeker elders heen sturen of handelingen uitvoeren als die persoon. Is de bezoeker een ingelogde beheerder, dan kan hetzelfde script proberen beheerhandelingen uit te voeren. Daarom wordt XSS in een beheerscherm zwaarder genomen dan XSS op een openbare pagina waar niemand inlogt.
Wat het betekent voor een PHP- of WordPress-site
WordPress-core zorgt zorgvuldig dat uitvoer wordt “geëscaped”, en het risico zit vooral in plugins, themaEen WordPress-thema is het ontwerp van je WordPress-site: het bepaalt hoe pagina's eruitzien en hoe ze zijn opgebouwd.’s en maatwerkcode die invoer tonen zonder dat te doen. Het is een van de meest gemelde soorten kwetsbaarheidEen kwetsbaarheid is een zwakke plek in software waar een aanvaller misbruik van kan maken, zoals een deur die niet goed op slot gaat. in pluginchangelogs, vaak met een opmerking als “escaping opgelost” of “stored XSS verholpen”.
Een content security policyEen Content Security Policy (CSP) is een regel die de browser vertelt van welke plekken jouw pagina bestanden en scripts mag laden. is een extra laag die de browser vertelt welke scripts op jouw pagina’s mogen draaien, waardoor een ingespoten script minder kan. Het vervangt het repareren van de code niet. Samen met andere securityheadersSecurityheaders zijn instructies die je website meestuurt en waarmee de browser van je bezoeker extra beveiligingsregels toepast. hoort het op je lijst als je naloopt hoe je site wordt geserveerd.
Een concreet voorbeeld
Denk aan een contactformulierplugin die de naam van de afzender in het beheerscherm toont. De code toont de naam precies zoals getypt. Iemand vult een naam in die een script bevat. Opent een beheerder de berichtenlijst, dan draait het script in de browser van de beheerder, met beheerrechten. De oplossing van de maker toont de naam als gewone tekst. Jouw oplossing is de update installeren, en berichten en plugins verwijderen die je niet nodig hebt.
Wanneer je handelt
Update plugins en thema’s als een changelog XSS noemt, en geef extra gewicht aan alles wat beheerschermen raakt. Controleer wie beheerdersaccounts heeft en verwijder wat je niet nodig hebt. Verwante aanvallen die op de database mikken, vind je onder SQL-injectieSQL-injectie is een aanval waarbij iemand via een formulier of webadres eigen opdrachten in de database van je site smokkelt..
Een site die uit vooraf gemaakte pagina’s bestaat en zonder PHP wordt geserveerd, heeft veel minder code die bezoekersinvoer toont, al blijven scripts van derden die je toevoegt hun eigen risico houden. Wil je dat verkennen, kijk dan naar onze aanpak voor een website zonder PHP. Toont een site inhoud die jij er niet hebt gezet, stuurt hij bezoekers weg of staat je website offline, vraag dan om onze hulp.
Veelgestelde vragen
Wat kan XSS met mijn bezoekers doen?
Een script dat in de browser van een bezoeker op jouw pagina draait, kan nepinhoud tonen, doorsturen of handelen met de rechten van de bezoeker op jouw site, bijvoorbeeld als ingelogde beheerder. De schade hangt af van wie de pagina bekijkt.
Wat is het verschil tussen stored en reflected XSS?
Stored XSS wordt op de site opgeslagen, bijvoorbeeld in een reactie, en raakt iedereen die het bekijkt. Reflected XSS zit in een link: het script draait alleen bij wie op die specifieke link klikt.
Is XSS hetzelfde als SQL-injectie?
Nee. SQL-injectie richt zich op de database achter de site. XSS richt zich op de browsers van de mensen die de site bezoeken.
Hoe voorkom je XSS?
Vooral met code die alle invoer als gewone tekst behandelt als hij op een pagina wordt getoond, plus een content security policy als extra laag. Beide zijn werk van de maker. Jouw taak is plugins en thema's bijwerken.