I denna uppgift utforskar vi en av de mest komplexa XSS-varianterna: DOM-based XSS. Denna typ av attack skiljer sig markant från både Reflected och Stored XSS eftersom den sker helt och hållet på klientsidan (användarens webbläsare) och inte involverar webbservern i exekveringsprocessen.
Sårbarheten uppstår när en webbapplikation använder JavaScript för att ta emot data från en osäker källa (som URL:ens fragment, window.location.hash) och sedan skriver ut denna data direkt till sidans DOM (Document Object Model). Eftersom servern aldrig ser den skadliga koden, kan vanliga server-baserade skyddsmekanismer inte upptäcka eller förhindra attacken.
http://example.com/dom.html#<script>alert('XSS!')</script>. Det viktiga att notera här är att allt efter # inte skickas till servern vid en HTTP-förfrågan.innerHTML för att skriva ut innehållet direkt i ett HTML-element. Eftersom innerHTML tolkar innehållet som HTML-kod, exekveras eventuella <script>-taggar.DOM-based XSS är särskilt svår att upptäcka eftersom den inte lämnar några spår i serverns loggar. Allt skadligt beteende sker på klientsidan, vilket kräver att man granskar den lokala JavaScript-koden noggrant för att hitta och åtgärda sårbarheten.
Den grundläggande regeln för att förhindra DOM-based XSS är att aldrig skriva data från osäkra källor till DOM-element utan att sanera det. Använd aldrig innerHTML, document.write() eller liknande funktioner med användarinmatning. Istället bör du använda säkrare metoder, som till exempel textContent, som alltid behandlar inmatningen som ren text, eller sanera inmatningen med betrodda bibliotek som till exempel DOMPurify innan den infogas i DOM:en.
Genom att förstå att klientsidans kod kan vara lika sårbar som server-sidans kod, kan du bygga säkrare webbapplikationer.