Reflected XSS in Login Redirect Parameter — Real Bug Bounty Case Study

Introduction

During a security assessment on a Bugcrowd program, I identified a Reflected Cross-Site Scripting (XSS) vulnerability in a login-related endpoint.

This issue allows an attacker to inject malicious JavaScript into a URL parameter that is reflected back into the application without proper sanitization. When a victim clicks a crafted link, the payload executes in their browser under the context of the trusted application.

Although this is a client-side vulnerability, its real-world impact can become serious when combined with phishing or session manipulation scenarios.

What is Reflected XSS?

Reflected XSS occurs when an application takes user input from a request and immediately includes it in the response without proper encoding or validation.

An attacker can craft a malicious link containing JavaScript payloads. When a user clicks the link, the script is executed in their browser within the context of the vulnerable website.

This allows attackers to perform actions such as executing scripts in the victim’s session, stealing sensitive information, or performing actions on behalf of the user.

Business Impact

If exploited, this vulnerability could enable an attacker to:

• Execute arbitrary JavaScript in the victim’s browser
• Conduct phishing attacks using a trusted domain
• Steal session-related information (depending on cookie security flags)
• Perform unauthorized actions as the victim user
• Damage user trust and platform reputation

Even though the exploit is client-side, the impact becomes significant in real user-targeted scenarios.

Methodology

The vulnerability was discovered using a structured reconnaissance and testing approach.

Parameter Discovery

I began by extracting hidden and exposed parameters across the target application using a parameter spider tool. This helped identify multiple potential injection points such as redirect-related parameters commonly used in login flows.

Among them, a specific parameter responsible for redirect behavior stood out as a high-interest candidate.

Automated Reflection Testing

After identifying potential endpoints, I used an automated reflection testing technique to detect unsanitized input reflections in the application responses,tool named kxss

This helped quickly identify parameters where user-controlled input was being reflected back into the HTML output without proper encoding.

The redirect parameter in the login endpoint showed clear signs of reflection.

Vulnerability Details

The issue exists in a login-related endpoint where a redirect parameter is used to control post-authentication navigation.

The parameter value is directly reflected into the response without proper sanitization or encoding, allowing script injection. and if you navigate to source code it will be reflected → initAuth: { invite_active: “”, invite_cid: “”, invite_email: “”, invite_name: “”, invite_token: “”, invite_uid: “”, next: “batman</script><script>alert(0)</script>”, reset_token: “”, reset_uid: “”, valid_token: “”, applied_verify: “”,

so first i closed the original </script> then inject my own simple script <script>alert(0)</script> This resulted in a visible JavaScript execution (alert popup), confirming the presence of Reflected XSS.

Root Cause

The root cause of this vulnerability is improper handling of user input in the redirect parameter.

The application fails to properly:

• Encode output before reflecting user input
• Sanitize special characters such as angle brackets
• Restrict or validate redirect destinations

As a result, user input is interpreted as executable HTML/JavaScript.

Recommendation

To mitigate this issue, the following security measures should be implemented:

• Proper output encoding based on context (HTML/JavaScript)
• Strict validation of redirect parameters using an allowlist approach
• Avoid directly reflecting user input in responses
• Use safe redirect mechanisms instead of raw user-controlled URLs
• Implement Content Security Policy (CSP) as an additional layer of defense

A secure design should only allow trusted internal paths for redirects rather than arbitrary user input.

Conclusion

This case demonstrates how seemingly harmless redirect parameters can become a vector for client-side attacks when input validation is missing.

By combining parameter discovery and reflection testing techniques, it was possible to identify and confirm a Reflected XSS vulnerability with minimal effort.

Even simple injection points can become high-risk issues when they exist in authentication or login flows, where user trust is highest.