DOM XSS – Client-Side Script Injection

Abstract

This penetration test was conducted in a controlled laboratory environment using the OWASP Juice Shop application.
The objective of this challenge was to identify and exploit a DOM-based Cross-Site Scripting (XSS) vulnerability.

By injecting a malicious payload into the search field, it was possible to execute arbitrary JavaScript code in the context of the victim’s browser. The vulnerability was caused by improper handling of user-controlled input in client-side JavaScript without sufficient sanitization or encoding.

This challenge demonstrates the risks associated with insecure DOM manipulation and highlights why client-side input handling must be treated as untrusted.

Preparation Documentation

Identified Vulnerability / Vulnerabilities and Risk Assessment

• Identified Vulnerability: DOM-based Cross-Site Scripting (XSS)
• Category: Cross-Site Scripting (XSS)
• OWASP Top 10 Mapping: A03: Injection
• Risk Assessment: Medium
• Potential Impact:
  • Execution of arbitrary JavaScript in the victim’s browser
  • Session hijacking or token theft
  • Defacement of application content
  • Phishing or redirection attacks

Known Exploits

• DOM XSS is a well-known vulnerability class.
• Commonly documented in:
  • OWASP Top 10 – A03: Injection
  • OWASP XSS Prevention Cheat Sheet
• Typical attack vectors include:
  • Unsafe usage of innerHTML
  • Direct insertion of user input into the DOM
  • Lack of output encoding in client-side code

Execution of the Penetration Test

• Affected Component: Global search functionality

• Input Vector: Search field in the application header

• Tools Used:

  • Web browser
  • Manual payload injection

• Testing Method:

  • Manual DOM-based XSS testing

• Assumptions and Constraints:

  • Test performed on a local OWASP Juice Shop instance
  • No authentication required
  • Scope limited to client-side code execution

Results Documentation

Accessible Information

• Ability to execute JavaScript code within the browser context
• Access to DOM, cookies (depending on flags), and client-side state

No backend data, credentials, or server-side configuration files were exposed during this challenge.

Exploitation Depth

• Successful execution of JavaScript via DOM manipulation
• Exploitation limited to the client-side environment
• No direct server-side compromise
• No privilege escalation or lateral movement observed

Discovery Process

• Manual testing of user input fields
• Observation that search input was reflected dynamically in the page
• Hypothesis that input might be written to the DOM without sanitization

Exploitation Process

1. Located the global search field in the application header.
2. Entered the following payload into the search input:

   <iframe src="javascript:alert(xss)"></iframe>
   

3. Submitted the search query.
4. The application dynamically processed the input.
5. The injected JavaScript executed successfully.
6. A browser alert was displayed, confirming DOM XSS.

Outcome

• DOM-based XSS vulnerability successfully exploited.
• Arbitrary JavaScript execution achieved in the browser context.
• The challenge “DOM XSS” was completed.
• Demonstrated lack of proper client-side input sanitization.

Mitigation Measures

• Avoid using dangerous DOM APIs such as innerHTML with untrusted input.
• Sanitize and encode all user-controlled data before inserting it into the DOM.
• Use safe alternatives like textContent instead of HTML injection.
• Implement a strict Content Security Policy (CSP).

Recommendations and Prioritization

• Priority: Medium
• Refactor client-side code to enforce proper output encoding.
• Introduce automated security testing for XSS.
• Apply CSP headers to reduce the impact of potential XSS vulnerabilities.
• Conduct regular code reviews focusing on DOM manipulation.