Knowledge about DOM-based stuff

❓ Questions Covered

• What is DOM-based XSS and how does it work?
• How to prevent it?
• How to detect DOM-based XSS?
• What are the most common protections?
• How can protections be bypassed?

🔎 What is DOM-based XSS and How Does it Work?

The Document Object Model (DOM) is an internal data structure that stores all of the objects and properties of a web page.
Developers can use JavaScript to dynamically read and modify the DOM.

• DOM-based XSS occurs when user-controllable input (source) is passed directly to a dangerous execution point (sink).
• Unlike reflected or stored XSS, DOM-based XSS is entirely client-side. The payload never reaches the server.
• Typical attack vector: tricking a victim into clicking a malicious link that modifies location.hash, location.search, etc.

Sources (user input)

• document.URL
• document.documentURI
• location.href, location.search, location.*
• window.name
• document.referrer

Sinks (execution points)

• HTML modification: document.write, element.innerHTML, outerHTML
• Behavior change: element.src
• Code execution: eval, setTimeout, setInterval, execScript

⚠️ Why is DOM-based XSS Dangerous?

• Can steal cookies, tokens, or sensitive data directly in the browser.
• Cannot be blocked by server-side filters, since anything after # (hash) is never sent to the server.
• Even large organizations have been found vulnerable.

🛡️ How to Prevent DOM-based XSS

OWASP Rules

Rule #1 – HTML Escape then JavaScript Escape

• Avoid innerHTML, outerHTML, document.write.
• Use textContent instead to safely render dynamic content.

Rule #2 – JavaScript Escape in Attribute Contexts

• Attributes like onclick, src, href must not receive unsanitized input.
• Use direct property assignments where possible.

Rule #3 – Avoid Untrusted Data in Event Handlers and Code

• Don’t place dynamic data directly in JavaScript contexts.
• Avoid dangerous functions like eval, setTimeout(string), setInterval(string).

Other Protections

• Don’t use URI fragments (#) for sensitive state.
• Enforce Content Security Policy (CSP) to restrict where scripts can load/execute.
• Use modern frameworks like React/Angular that auto-escape by default.

🕵️ How to Detect DOM-based XSS

• Server-side logs won’t show it, since payloads often hide after #.
• Use client-side scanners like Acunetix, Burp DOM Invader, or manual payload testing.
• Look for code using unsafe sinks (innerHTML, document.write).
• Test inputs like:
  html Copy

  " onmouseover="alert(1)

• Insert alert(document.cookie) or data:text/html,alert(0) to verify execution.

🔓 How Can Protections be Bypassed?

• URL encoding / double encoding (%c0f%af instead of /).
• Injecting payloads via query strings, fragments, or cookies.
• Overly permissive CSPs (e.g., script-src *).
• Sanitizers that miss edge cases (nested tags, template injections).

✅ Key Takeaways

• DOM-based XSS is client-side only and bypasses traditional server-side protections.
• Always separate sources (untrusted input) from sinks (execution points).
• Use safe APIs like textContent.
• Apply defense-in-depth with CSP and code reviews.