DOM-based XSS treedt op wanneer kwaadaardige scripts worden uitgevoerd via client-side JavaScript die het DOM op een onveilige manier wijzigt. In tegenstelling tot traditionele XSS hoeven deze aanvallen niet te interageren met de server. Ze exploiteren doorgaans kwetsbaar JavaScript dat gegevens verwerkt van onveilige bronnen zoals URL-parameters. Preventie vereist zorgvuldige omgang met gebruikersinvoer in client-side code en juiste output-encoding.
DOM-based cross-site scripting is een client-side fout waarbij de kwetsbaarheid volledig in de JavaScript van de pagina leeft in plaats van in de server-response. De pagina leest data uit een bron die de aanvaller kan beïnvloeden, vaak het URL-fragment (location.hash), de querystring, document.referrer of web storage, en geeft die door aan een gevaarlijke sink zoals innerHTML, de document write-methode of eval zonder ze te saneren. De browser parseert de data van de aanvaller vervolgens als markup of code en voert die uit. Omdat de besmette waarde de browser mogelijk nooit verlaat, kan de payload achter de hash in een URL zitten, die servers niet ontvangen, dus de server ziet de aanval nooit en kan die niet loggen of filteren.
DOM XSS verleent dezelfde macht binnen de origin als andere XSS: het lezen van tokens en paginagegevens, het vervalsen van requests en het herschrijven van de interface, allemaal onder de vertrouwde origin van de site. Het is makkelijk over het hoofd te zien omdat server-side verdedigingen, web application firewalls en request-logging niet gelden voor data die in de browser blijft of zich in het URL-fragment verbergt. Moderne single-page applicaties zijn bijzonder kwetsbaar, aangezien routing, templating en rendering allemaal client-side gebeuren en zwaar leunen op URL- en storagewaarden. Naarmate frameworks meer logica naar de browser duwen, vermenigvuldigen DOM-based sinks zich, en één onveilige toewijzing aan innerHTML in een veelgebruikte component kan elke pagina blootstellen die deze rendert.
Voorkom DOM XSS door onvertrouwde data uit gevaarlijke sinks te houden: geef de voorkeur aan textContent boven innerHTML, vermijd eval en verouderde document-write-methoden, en route alle HTML die je moet invoegen via een vertrouwde sanitizer of de Sanitizer API en Trusted Types van de browser. Databinding in frameworks en een Content Security Policy verkleinen het resterende oppervlak. cside herschrijft de DOM-logica van je applicatie niet, maar het bewaakt wel wat er in de browser tijdens runtime uitvoert. De Script-methode analyseert third-party scriptpayloads, kan kwaadaardig gedrag blokkeren en registreert wat er daadwerkelijk draaide, zodat een geïnjecteerd of gecompromitteerd script dat exfiltratie probeert, wordt betrapt op gedrag in plaats van op bron, en dat bewijs ondersteunt PCI DSS 6.4.3 en 11.6.1.
Bij reflected XSS injecteert de server de payload in de HTML die hij teruggeeft. Bij DOM-based XSS is de server-response schoon en zit de fout in client-side JavaScript die een door de aanvaller beheerste waarde leest en die in een gevaarlijke sink schrijft. De exploit kan in het URL-fragment leven, dat de server nooit ontvangt.
Omdat de payload de server vaak nooit bereikt. Waarden die achter de hash in een URL worden geplaatst, blijven in de browser, en andere bronnen zoals local storage of de referrer worden puur client-side verwerkt. Een firewall inspecteert alleen verkeer dat hij ziet, dus is hij blind voor aanvallen die volledig binnen de DOM worden uitgevoerd.
We answer client-side security questions every day. Bring yours.