Reflected XSS treedt op wanneer kwaadaardige scripts worden opgenomen in URL's en onmiddellijk worden teruggekaatst naar gebruikers zonder juiste sanitisatie. Deze aanvallen vereisen doorgaans social engineering om gebruikers te overtuigen op kwaadaardige links te klikken. Preventie omvat inputvalidatie, output-encoding en implementeren van Content Security Policy headers.
Reflected cross-site scripting gebeurt wanneer een webapplicatie invoer uit een request overneemt, meestal een URL-queryparameter, een zoekterm of een formulierveld, en die rechtstreeks terug in de HTML-response weergeeft zonder ze te encoderen. Als een aanvaller een link maakt waarvan de parameter een script bevat, weerspiegelt de server dat script in de pagina en voert de browser van het slachtoffer het uit alsof de site het zelf had geschreven. De payload wordt nergens opgeslagen; hij bestaat alleen in dat ene request, dus elke aanval heeft een nieuwe kwaadaardige link nodig. Een typische aanvalsroute is een zoekresultatenpagina die je zoekopdracht letterlijk toont, of een foutpagina die een niet-geëscapete waarde uit de URL herhaalt.
Omdat het geïnjecteerde script in de browser van het slachtoffer draait onder de eigen origin van de site, erft het het vertrouwen van die origin. Het kan niet-HttpOnly cookies, sessietokens en pagina-inhoud lezen, formulieren versturen of veranderen wat de gebruiker ziet, wat sessiekaping, diefstal van inloggegevens en phishing mogelijk maakt die van het echte domein lijkt te komen. Reflected XSS steunt meestal op social engineering: een aanvaller moet het slachtoffer op een geprepareerde link uit e-mail, chat of een kwaadaardige advertentie laten klikken, dus richt het zich vaak op ingelogde gebruikers van bank-, webmail- of adminpanelen. Eén kwetsbare parameter kan elk account compromitteren waarvan de eigenaar de link opent.
De kerndefensies liggen aan de kant van de ontwikkelaar: valideer invoer en pas contextbewuste output-encoding toe zodat weergegeven waarden als tekst renderen, nooit als markup of script. Een Content Security Policy voegt een tweede laag toe door te beperken welke scripts mogen draaien, en auto-escaping van frameworks dekt de meeste gevallen standaard af. cside is geen vervanging voor output-encoding; het richt zich op de third-party scripts die een pagina laadt. Waar een XSS-voet aan de grond of een gecompromitteerd vendorscript probeert te laden of via de browser data te exfiltreren, inspecteert de Script-methode van cside de daadwerkelijke JavaScript-payload, kan dat gedrag in real time blokkeren en houdt een forensisch verslag bij, wat ook de script-monitoringvereisten van PCI DSS 6.4.3 en 11.6.1 ondersteunt.
De impactradius is meestal kleiner, omdat de payload niet op de server wordt opgeslagen, dus treft het alleen gebruikers die een specifiek geprepareerde link openen in plaats van iedereen die een pagina bekijkt. Maar de mogelijkheden in de browser zijn identiek, en tegen een waardevol ingelogd doelwit kan één klik genoeg zijn om een account te kapen.
Nee. De HttpOnly-vlag verbergt een cookie alleen voor JavaScript, dus het beperkt tokendiefstal, maar een gereflecteerd script kan nog steeds binnen de sessie handelen, paginagegevens lezen, requests versturen en de interface bekladden. HttpOnly is een nuttige mitigatie, geen oplossing; je hebt nog steeds output-encoding en een sterke CSP nodig.
We answer client-side security questions every day. Bring yours.