September 9, 2026
How to Understand Reflected XSS
(This is a Simple POC).
By Raja Muhammad Kurnia Setyawan
2 min read
ุจุณู ุงููู ุงูุฑุญู ู ุงูุฑุญูู
I would like to share a short write-up about XSS, specifically Reflected XSS, including how I identified and reproduced the vulnerability.
The issue had not been fixed and was still reproducible at the time of testing.
Cross-Site Scripting (XSS) is a vulnerability that occurs when an application allows an attacker to inject HTML or JavaScript that is then processed by a victim's browser.
XSS is generally divided into three primary types:
- Reflected XSS โ the payload is sent through a request and immediately reflected by the server in the response.
- Stored XSS โ the payload is stored by the application and later served to other users.
- DOM-based XSS โ the vulnerability occurs on the client side when JavaScript manipulates the DOM using attacker-controlled input.
- Blind XSS โ a payload is injected into a location that is processed later by another user or system, often without direct visibility to the attacker. It can be used to target privileged users or administrative interfaces and receive callbacks through external infrastructure.
In this case, I identified a Reflected XSS vulnerability in the prev parameter.
I first tested the prev parameter with a simple marker:
https://www.example.com/webstore/goods/view?prev=TEST&productIdx=1000000385https://www.example.com/webstore/goods/view?prev=TEST&productIdx=1000000385I then inspected the page source:
view-source:https://www.example.com/webstore/goods/view?prev=TEST&productIdx=1000000385view-source:https://www.example.com/webstore/goods/view?prev=TEST&productIdx=1000000385The parameter was reflected inside a JavaScript block:
The prev parameter was reflected inside an existing JavaScript block. I then added </scricpt> to the input, causing the browser to terminate the existing JavaScript block. The input after it was then interpreted as HTML, confirming HTML Injection.
I then tested whether I could terminate the existing JavaScript context and inject HTML using:
</scricpt><h1>TEST</h1></scricpt><h1>TEST</h1>The <h1> element was rendered successfully, confirming HTML injection.
I then used an SVG element with an onload event:
</scricpt><svg onload=prompt(1)></scricpt><svg onload=prompt(1)>
The JavaScript executed successfully, confirming Reflected XSS in the prev parameter.
Impact
The impact of this vulnerability depends heavily on where the affected parameter is reflected and how the application handles authentication and sensitive actions.
A successful Reflected XSS allows an attacker to execute arbitrary JavaScript in the victim's browser under the affected website's origin. This can be used to perform actions on behalf of the victim, manipulate the page, or facilitate phishing and other social engineering attacks.
When combined with social engineering, an attacker could potentially trick a victim into opening a crafted URL and interacting with malicious content. Depending on the application's security controls and the victim's privileges, this could contribute to account compromise or account takeover.
In a formal security assessment, Reflected XSS is often rated Low to Medium severity, but the actual risk should be determined based on the affected location, required user interaction, victim privileges, authentication mechanisms, and the potential attack chain.
This is a well-known FPS game website in Indonesia. The finding had already been discovered by my friend, Just R a long time ago. While exploring the website, I came across the same issue and decided to reproduce it to refresh my XSS recognition.