Stored XSS (Cross-Site Scripting) treedt op wanneer kwaadaardige scripts permanent worden opgeslagen op doelservers en later worden weergegeven aan gebruikers die getroffen pagina's bezoeken. Dit type XSS is bijzonder gevaarlijk omdat het alle bezoekers van de gecompromitteerde pagina treft. Preventie vereist juiste inputvalidatie, output-encoding en content security policies.
Stored cross-site scripting, ook wel persistent XSS genoemd, treedt op wanneer een applicatie door een aanvaller aangeleverde inhoud accepteert, opslaat en die later aan andere gebruikers serveert zonder correcte encoding. Het kwaadaardige script wordt één keer geschreven, in een reactieveld, een productreview, een forumpost, een gebruikersprofiel of een supportticket, en voert vervolgens uit in de browser van elke bezoeker die de getroffen pagina laadt. Anders dan bij reflected XSS is er geen geprepareerde link of social engineering per slachtoffer nodig; de payload wacht op de server en gaat automatisch af. Omdat de geïnjecteerde markup onderdeel wordt van de normale inhoud van de pagina, kan hij blijven bestaan zolang het record bestaat en nieuwe bezoekers blijven infecteren.
Stored XSS is de gevaarlijkste XSS-variant omdat hij zichzelf verspreidt en iedereen raakt die de vergiftigde pagina bekijkt. Een payload die in een populaire thread of een gedeeld profiel is geplaatst, kan in duizenden sessies draaien, en als hij ergens belandt waar een beheerder kijkt, kan hij escaleren tot een volledige overname van het account of de applicatie. Draaiend onder de origin van de site kan het script sessietokens en niet-HttpOnly cookies stelen, toetsaanslagen en formuliergegevens vastleggen, zich als het slachtoffer voordoen of zich in meer records nestelen. Historische XSS-wormen verspreidden zich precies zo, door zichzelf toe te voegen aan elk profiel dat ze aanraakten en bij elke weergave nieuwe gebruikers te infecteren.
De verdediging ligt vooral aan de server- en codekant: valideer en saneer invoer bij binnenkomst, encodeer output voor de exacte context bij uitgang, en schoon alle rijke HTML op met een gecontroleerde sanitizer voordat deze de DOM bereikt. Een Content Security Policy beperkt wat een geïnjecteerd script kan doen, zelfs als er eentje doorglipt. cside vervangt deze controles voor je eigen applicatiecode niet. Waar het helpt, is de runtime-laag in de browser: het routeert third-party scripts via een Script-methode, analyseert de JavaScript-payload die daadwerkelijk draait, kan kwaadaardig gedrag zoals data-exfiltratie in real time blokkeren en bewaart forensische verslagen die PCI DSS 6.4.3 en 11.6.1 ondersteunen.
Omdat de payload server-side wordt opgeslagen en aan iedereen wordt geserveerd die de getroffen pagina opent, heeft hij geen link of klik per slachtoffer nodig. Eén injectie kan in de sessie van elke bezoeker draaien, en als een beheerder hem bekijkt kan de aanvaller verhoogde toegang krijgen, wat stored XSS een veel grotere impactradius geeft.
Nee. De kwetsbaarheid gaat over hoe inhoud wordt gerenderd, niet over waar ze wordt bewaard. Als opgeslagen gegevens later als HTML in een pagina worden ingevoegd zonder encoding of sanitatie, zullen ze uitvoeren. Markdown kan zelfs risico toevoegen als het ruwe HTML of onveilige links toestaat, dus de output moet nog steeds gesaneerd worden.
We answer client-side security questions every day. Bring yours.