- AHB | ~root@clover:
- Posts
- Popping Alerts in a Login Flow: $$$ for a Reflected XSS
Popping Alerts in a Login Flow: $$$ for a Reflected XSS
A Hacker's Blog | ~root@clover:
clover
April 25, 2025
The Low Down [TL;DR]:
Hello All, It has been far too long since I’ve sat and wrote a post for this website. Though, I’m not sure many have noticed how long it’s been since the last post 😅. Anyways, I’m going to try to be better about posting these so I hope you enjoy this one!
I discovered a Reflected Cross-Site Scripting (XSS) vulnerability in a login-related subdomain of a major organization’s web application. By exploiting an unsanitized target parameter in a redirect endpoint, I crafted a payload that bypassed a WAF and executed arbitrary JavaScript, popping an alert with document.domain. I reported this to the organization’s bug bounty program via HackerOne, where it was triaged, retested, and eventually resolved, earning me a nice $XXX bounty for the medium-severity find.
The Hunt for XSS
While poking around a target’s subdomains (all within the *.target.com scope), I stumbled upon a login-related subdomain hosting a redirect endpoint: /login/redirectTarget.jsp?target=. The target parameter caught my eye—it’s a classic spot for XSS if input sanitization is weak. My goal was to see if I could inject JavaScript that would execute in a user’s browser, ideally proving impact with a simple alert().
The page’s JavaScript included a function called loadParentURL(), which was triggered on page load via a setTimeout. Here’s the vulnerable code:
function loadParentURL() {
document.cookie = "INVALID_CREDENTIALS=null";
parent.location.href = 'attacker controlled';
}
window.onload = function() {
setTimeout("loadParentURL()", 500);
};The issue? The target parameter was directly assigned to parent.location.href without sanitization. This meant I could inject a javascript: URL that would execute when the function ran. Even better, the page parsed location.hash via decodeURI(), giving me a way to append encoded payloads.
Crafting the Payload
My first instinct was to try a basic XSS payload, but I knew a Web Application Firewall (WAF)—specifically Akamai Ghost—was in play. Simple payloads like <script>alert(1)</script> would likely get blocked. After some trial and error, I crafted a payload that leveraged the javascript: protocol and the page’s own logic:
javascript:kikou=document;kikou.body.innerHTML=decodeURI(location.hash)#<img%20src=x%20onerror=alert(document.domain)>This payload works by:
Setting parent.location.href to a javascript: URL that assigns the document object to kikou.
Using kikou.body.innerHTML to render the decoded contents of location.hash.
Appending an encoded <img> tag with an onerror event that triggers alert(document.domain).
The full proof-of-concept URL looked like this:
https://[redacted-subdomain].target.com/login/redirectTarget.jsp?target=javascript:kikou=document;kikou.body.innerHTML=decodeURI(location.hash)#%3Cimg%20src=x%20onerror=alert(document.domain)%3EWhen clicked, the URL loaded the page, executed the JavaScript, and popped an alert showing the domain—clear evidence of XSS. The WAF didn’t block it, likely because the payload avoided common XSS patterns and relied on the page’s own logic.
XSS Popped
Impact of the Vulnerability
Reflected XSS is no joke. If exploited, an attacker could:
Steal session cookies or login credentials by injecting malicious scripts.
Manipulate page content to trick users into revealing sensitive info (e.g., phishing forms).
Redirect users to malicious sites or perform actions on their behalf.
Since this was a login-related subdomain, the impact was significant—attackers could target users during authentication, potentially compromising accounts. The medium severity (CVSS 6.5) reflected this risk, balancing the need for user interaction (clicking a malicious link) against the potential for data theft or account takeover.
Reporting the Bug
I submitted the report to the organization’s HackerOne program on April 19, 2024, including the PoC URL, payload details, and a screenshot of the alert. I explained the vulnerability’s root cause (unsanitized target parameter) and its impact clearly, ensuring the triage team could reproduce it. The report was triaged quickly, but resolution took months, with retesting completed in February 2025. I followed up a couple of times to nudge the process along, and the team eventually confirmed the fix.
Final Thoughts
This XSS was a fun find, blending classic parameter tampering with WAF evasion. The long resolution timeline tested my patience, but the $XXX bounty made it worthwhile. It’s a reminder that even well-protected apps can have subtle flaws in redirect logic. My takeaway? Always test target-like parameters, and don’t shy away from tweaking payloads to slip past WAFs. I’m grateful to the program for their thorough review and fair reward—onto the next bug!