⟫ Disclosure Timeline
⟫ Reconnaissance
During reconnaissance of the government legal management platform, all administrative data management interfaces were mapped. The "Master Kategori Produk Hukum" (Legal Product Category Management) feature was identified as a high-value target due to its role in storing and displaying categorization data across multiple views. Input fields including category name, description, and metadata were systematically tested for injection vulnerabilities using Burp Suite and browser DevTools.
⟫ Vulnerability Discovery
The category name input field accepted arbitrary HTML and JavaScript without any server-side or client-side input validation. When a new category was created with a crafted payload, the input was stored directly in the database and subsequently rendered without output encoding on the category listing page, the category detail view, and the administrative dashboard. This confirmed a classic stored (persistent) XSS vulnerability.
⟫ 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.
<b>test</b><i>italic</i><script>alert(document.domain)</script><img src=x onerror=alert(document.domain)>"><img src=x onerror=alert(document.domain)>⟫ Tooling
⟫ Chaining Strategy & Escalation
The stored XSS executes every time any user (including administrators) views the category listing page. Since the payload is persistent, it does not require user interaction beyond normal navigation. In a real attack scenario, this could be weaponized for: (1) session hijacking by stealing admin cookies, (2) administrative account takeover via session token exfiltration, (3) keylogging on administrative pages, (4) defacement of the legal document management system, or (5) phishing by injecting fake login forms into the trusted government domain. The PoC was limited to alert(document.domain) to demonstrate impact without causing harm.
⟫ Root Cause Analysis
The application stored user-supplied input directly into the database without any input validation or sanitization. When rendering the stored data, the application inserted it directly into the HTML response without context-aware output encoding. There was no Content Security Policy (CSP) header configured to mitigate inline script execution. The fundamental issue is a lack of defense-in-depth: no input validation, no output encoding, and no CSP — all three layers were missing.
⟫ 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.