Vulnerability Type: Stored Cross-Site Scripting (XSS)
Attack Vector
The vulnerable application stores user input (e.g., comments) directly in the database and reflects it un-sanitized in the HTML response. Unlike reflected XSS, stored XSS persists on the server, affecting all users who view the compromised page.
Exploitation Steps
- Identify the Input Vector: A comment form reflects user input (name, email, website, and comment) directly in the HTML response.
- Craft Malicious Payload: Inject a JavaScript payload via the comment field: <script>alert(1)</script>
- Trigger the Exploit:
- Enter the payload into the comment box, along with dummy values for name, email, and website.
- Click “Post comment” to submit the payload.
- The server stores the input un-sanitized and displays it to all visitors.
- Confirmation:
- Navigate back to the blog page.
- The `alert(1)` script executes automatically for anyone viewing the comment, confirming stored XSS.
Mitigation Strategies
- Output Encoding: Encode stored data before rendering it in HTML (e.g., convert `<script>` to `<script>`).
- Input Validation/Sanitization:
- Reject or sanitize HTML/JavaScript in user-submitted content (e.g., strip `<script>` tags).
- Use allowlists for safe input (e.g., Markdown instead of raw HTML).
- Content Security Policy (CSP): Restrict inline scripts and unsafe eval() to mitigate impact.
- Database Safeguards: Store sanitized or encoded versions of user input.
Key Takeaway
Stored XSS is more dangerous than reflected XSS because it persists on the server and affects multiple users. This lab underscores the importance of sanitizing both input and output to prevent persistent script injection.
