XSS Injection – Stored HTML Injection Injection via Search Function

Abstract

This penetration test was conducted in a controlled laboratory environment using the OWASP Juice Shop application.
The objective of this challenge was to exploit a Cross-Site Scripting (XSS) / HTML Injection vulnerability by injecting executable HTML content into the global search field.

By submitting an <iframe> element embedding an external SoundCloud player, it was possible to inject and render third-party content directly within the application. This behavior demonstrates insufficient input validation and output encoding, allowing untrusted user input to be interpreted as active HTML.

Preparation Documentation

Identified Vulnerability / Vulnerabilities and Risk Assessment

• Identified Vulnerability: HTML Injection / XSS via unsanitized user input
• Category: Cross-Site Scripting (XSS)
• OWASP Top 10 Mapping: A03 – Injection
• Risk Assessment: Medium
• Potential Impact:
  • Execution of arbitrary HTML and JavaScript
  • Content injection and UI manipulation
  • Phishing or malicious redirection
  • Foundation for more advanced XSS-based attacks

Known Exploits

• HTML Injection and XSS are well-documented vulnerability classes.
• Common references:
  • OWASP Top 10 – A03: Injection
  • OWASP XSS Prevention Cheat Sheet

Execution of the Penetration Test

• Affected Component: Global search field

• Input Vector: Search input in the application header

• Tools Used:

  • Web browser
  • Manual payload injection

• Testing Method:

  • Manual input-based XSS testing

• Assumptions and Constraints:

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

Results Documentation

Accessible Information

• Ability to inject and render external content
• Execution of active HTML elements within the application context
• No direct access to backend data or credentials

Exploitation Depth

• Successful rendering of a third-party iframe
• Exploitation limited to client-side content injection
• No privilege escalation or server-side compromise observed

Discovery Process

• Manual testing of the search input field
• Observation that user input was rendered dynamically
• Hypothesis that HTML tags were not filtered or encoded

Exploitation Process

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

   <iframe
     width="100%"
     height="166"
     scrolling="no"
     frameborder="no"
     allow="autoplay"
     src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/771984076&color=%23ff5500&auto_play=true&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true"
   >
   </iframe>
   

3. Submitted the search query.
4. The application rendered the iframe as active HTML.
5. The embedded SoundCloud player loaded and autoplayed.
6. Successful XSS / HTML Injection confirmed.

Outcome

• Arbitrary HTML content was injected and rendered.
• External media content executed within the application.
• The challenge “XSS Injection” was completed.
• Demonstrated lack of proper input sanitization and output encoding.

Mitigation Measures

• Sanitize all user-controlled input before rendering.
• Encode output depending on context (HTML, attribute, JS).
• Disallow or strictly whitelist HTML tags in search inputs.
• Implement a restrictive Content Security Policy (CSP).
• Avoid rendering raw HTML from user input.

Recommendations and Prioritization

• Priority: Medium
• Refactor search functionality to treat input as plain text.
• Introduce automated XSS testing in the CI pipeline.
• Conduct code reviews focusing on dynamic DOM rendering.
• Monitor and log suspicious input patterns.