⟫ Disclosure Timeline
⟫ Reconnaissance
During reconnaissance of the government data portal, all user-facing input fields were mapped including search forms, filter parameters, and URL query strings. The search functionality at /search?q= was identified as reflecting user input directly into the HTML response body without proper encoding. Browser DevTools and Burp Suite were used to intercept and analyze the request/response cycle.
⟫ Vulnerability Discovery
The search parameter value was reflected inside an HTML attribute and also within a JavaScript context in the response page. Initial testing with standard XSS payloads revealed that a server-side blacklist filter was active, blocking common attack patterns. However, the filter operated on a keyword-matching basis rather than proper output encoding, suggesting bypass potential.
⟫ Filter Bypass Analysis
Payloads are intentionally sanitized for responsible disclosure and portfolio presentation.
⟫ Payload Analysis
All payloads below are sanitized proof-of-concept examples. No active exploitation code is shown.
<script>alert(document.domain)</script><img src=x onerror=alert(1)><ScRiPt>alert(1)</ScRiPt>
%3Cscript%3Ealert(1)%3C/script%3E"><img src=x onerror=eval(String.fromCharCode(97,108,101,114,116,40,100,111,99,117,109,101,110,116,46,100,111,109,97,105,110,41))>/search?q="><img+src=x+onerror=eval(String.fromCharCode(97,108,...))>⟫ Tooling
⟫ Chaining Strategy & Escalation
The reflected XSS executes in the context of the government data portal origin. In a real attack scenario, this could be weaponized via a crafted URL sent to an authenticated user. Potential escalation includes: session cookie theft (if HttpOnly flag is not set), DOM manipulation to display phishing content, keylogging on the current page, or redirecting to an attacker-controlled domain. The PoC was limited to alert(document.domain) to demonstrate the vulnerability without causing harm. No cookies, tokens, or user data were accessed during testing.
⟫ Root Cause Analysis
The application relied on a server-side blacklist filter that matched specific keywords (script, onerror, onload, javascript:) instead of implementing proper context-aware output encoding. The filter did not account for JavaScript string construction functions like String.fromCharCode() or eval(), allowing obfuscated payloads to pass through. The fundamental issue is using input validation as the sole defense against XSS rather than output encoding at the point of rendering.
⟫ Impact Assessment
⟫ Remediation
This case study follows responsible disclosure practices. All sensitive data including endpoints, credentials, customer information, and active exploitation payloads have been redacted or sanitized. The vulnerability was reported through the official bug bounty program and has been resolved.