Reflected Cross-Site Scripting in Hidden Input Fields
--
About XSS?
Cross-Site Scripting is a type of vulnerability that allows an attacker to inject JavaScript code into an application, deceiving the application into treating it as legitimate code. This can be exploited for malicious purposes, including stealing session cookies, credentials, credit card information, and more.
How did I discover it?
I embarked on a cybersecurity adventure by selecting a VDP with an extensive scope. With curiosity as my guide, I randomly picked an endpoint, only to find it leading to yet another. But instead of turning back, I thought, ‘Let’s fuzzing; who knows what intriguing discoveries lie ahead?
After examining several routes, I determined that the application was built using the .NET framework. This led me to perform fuzzing again, but this time using extensions such as .asp and .aspx.
Upon visiting the page, an intriguing message, ‘Invalid request was submitted.’ caught my eye, seemingly devoid of any functions. Yet, the response, as revealed by ffuf, displayed a Content-Length of 2676. This prompted me to delve into the source code, driven by curiosity.
<form name="frmMain" action="/refer.asp" method="post">
<input id="l" name="hOK" type="HIDDEN" value="">
<input type="hidden" name="l" value="">
</form>While examining the source code, it was clear that the form was designed to be submitted using the POST method. Yet, curiosity led us to wonder: what if we attempted to send it using GET? The result was rather unexpected — the request was accepted
At that moment, a memory stirred — Gareth Heyes’ article on XSS lurking within hidden parameters. Intrigued, I revisited it with a fresh perspective, setting out to craft the perfect payload.
After experimenting with some payloads, success came knocking as I managed to trigger the much-sought-after popup using the following payload:
l=default" accesskey="X" onclick="alert(document.domain)It’s worth highlighting that for this vector to work, we need to convince the user to press a specific key combination. In Firefox on Windows/Linux, it’s ALT+SHIFT+X, and on OS X, it’s CTRL+ALT+X.
In the source code, it would appear somewhat like this:
#Before Inject
<input type="hidden" name="l" value="">
#After Inject
<input type="hidden" name="l" value="default" accesskey="X" onclick="alert(document.domain)">An interesting takeaway from this journey was the encounter with several 400 errors. Despite these hurdles, I managed to unearth an XSS vulnerability. The lesson here? Don’t always take HTTP status codes like 400, 404, or 500 at face value. Keep forging ahead in your quest, and happy hunting!
