Executive Summary
A Reflected Cross-Site Scripting (XSS) vulnerability was discovered in the login=badanusaha parameter at the /Landing/Auth endpoint of pasti.pasuruankota.go.id. The vulnerability enables attacker-controlled JavaScript execution in the context of the target domain when a victim visits a specially crafted URL. This can lead to session theft, phishing, in-page CSRF, defacement, and other high-impact outcomes.
What is Reflected XSS?
Reflected XSS occurs when attacker-controlled input is sent to a web application (commonly via query parameters, form fields, or headers) and the application reflects that input back into the HTTP response without proper context-aware escaping or sanitization. Since the payload is not stored on the server, exploitation typically involves sending the victim a specially-crafted URL; when the victim visits the URL, the injected script runs within the target domain in the victim's browser.
Key characteristics:
- Non-persistent (payload is not stored server-side).
- Exploitation requires victim interaction (clicking the malicious URL).
- Injection can occur in multiple contexts (HTML body, attributes, inline JS, URL, or DOM-based client-side sinks).
Why it is dangerous:
- Injected scripts execute with the privileges of the site (same-origin), allowing reading the DOM, making authenticated requests using cookies, or exfiltrating data to attacker-controlled servers.
- Impacts include session theft, data exfiltration, inline phishing pages, and more.
Simple flow:
- Attacker crafts a URL containing payload:
https://target.example/search?q=<script>...(encoding if needed). - Victim clicks the URL (phishing, social engineering).
- Server returns a page that reflects
qwithout escaping. - Victim's browser executes the script; attacker can then perform malicious actions.
Difference from Stored XSS: Stored XSS persists the payload on the server (e.g., in a database) and affects all visitors; reflected XSS only triggers when the crafted URL is visited.
Classification
- Severity: High
- CVSS (claimed): 7.1
- Type: Reflected XSS (non-persistent)
Vulnerability Description
The badanusaha parameter reflects user input into the response without adequate sanitization or context-aware escaping. A basic payload like <script>alert(1)</script> initially triggered a server error (indicating inconsistent input handling), but an obfuscated/URL-encoded variant successfully bypassed the filters and produced a reflected XSS. The evidence indicates insufficient canonicalization and inconsistent filtering logic.
Impact
- Session cookie theft (if cookies are not
HttpOnly) → account takeover. - Actions on behalf of the user via authenticated requests.
- In-page phishing by rendering fake login prompts.
- Defacement of public pages.
- Reputational & compliance risks for a government service.
Reproduction Steps
- Use a test environment or obtain explicit permission before testing on production.
- Visit the following URL: https://pasti.pasuruankota.go.id/Landing/Auth?login=badanusaha%3C%2FScriPt%3E%3CsCripT+class%3Ddalfox%3Ealert%281%29%3C%2FsCriPt%3E
- The payload executes and shows an
alert(1)popup if the endpoint is vulnerable.

Payload
%3C%2FScriPt%3E%3CsCripT+class%3Ddalfox%3Ealert%281%29%3C%2FsCriPt%3E
Root Cause
- Lack of canonicalization before validation allowed encoded/mixed-case payloads to bypass filters.
- Output reflection without proper escaping.
- Poor error handling that may reveal processing details.
Impact
- Session cookie theft (if cookies are accessible via JS).
- Actions performed on behalf of the user (authenticated requests).
- Inline phishing or credential harvesting.
- Reputational and compliance issues for a government service.
Conclusion
The reflected XSS in the badanusaha parameter is a serious security issue that should be remediated promptly by normalizing input, enforcing whitelist validation, and applying context-aware escaping. Defensive layers like CSP and cookie hardening are strongly recommended.
Document prepared for contribution during PKL / internship.