Security article
Stored XSS into HTML context with nothing encoded
Stored XSS in blog comments: user input is persisted and rendered into HTML with no sanitization or encoding. Submitting a payload like <svg/onload=alert(1)> executes alert() when the post is viewed.
🎯 Objective
Find and confirm a stored cross-site scripting (XSS) in the comment functionality. Exploit by submitting a comment that executes alert() when the blog post is viewed.
🧭 Scope / Setup
- Tooling: Browser (comment form), optional proxy for recording
- Target: Blog post comment field that persists and renders comments into HTML
- Precondition: Authorized lab environment
🔎 Approach
- Submit a comment containing the payload.
- Open the blog post (or have another user/view) and observe whether the payload executes.
🧪 Test Payload (used)
<svg/onload=alert(1)
✅ Outcome
Stored XSS in blog comments: input is persisted and rendered into HTML. I tested <script>, but it showed as â> in the comment — likely due to server-side sanitization/escaping or a character-encoding (UTF-8 vs CP1252) mis-decode (mojibake) that altered the payload and prevented execution.
- If
alert()fires when the post is viewed, the stored XSS is confirmed. - If the payload is visible but not executed, note the exact rendering context and adjust testing accordingly.
🛡️ Mitigations
- Apply context-aware output encoding when rendering user content.
- Sanitize and whitelist HTML elements/attributes server-side; prefer stripping dangerous tags or using a safe HTML sanitizer.
- Use a WAF as an additional layer of defence only — fix the root cause with secure coding and proper encoding.
📝 Notes
- Lab has no CSP/CORS protections and backend does not escape input; direct injection into HTML can execute.
- Use controlled lab environments only and avoid testing on live sites without authorization.
- Screenshot (for reference):
