XSS for CSRF: Unauthorized Actions

Hello! Welcome back to the course.

In our last lesson, you learned how to escalate a Cross-Site Scripting (XSS) vulnerability into a full account takeover by stealing session cookies. This is a classic and powerful attack. However, as we briefly discussed, developers can set an HttpOnly flag on cookies, which instructs the browser to prevent client-side scripts like JavaScript from accessing them.

This brings up a crucial question: If you can't access document.cookie, is an XSS vulnerability useless? Absolutely not.

Today, we'll explore a more sophisticated way to leverage XSS. Instead of stealing data, we will command the victim's browser to perform actions on our behalf. Your learning outcome is to craft an XSS payload to perform unauthorized actions on behalf of a victim user, a technique often called "CSRF via XSS". This demonstrates that even with HttpOnly cookies, XSS can still lead to critical impacts like account takeover.

1. From Stealing to Commanding: Bypassing CSRF Protection

First, let's quickly define Cross-Site Request Forgery (CSRF). It's an attack that tricks an authenticated user into submitting a request to a web application that they did not intend to. For example, an attacker could host a webpage with an image tag whose src attribute points to https://your-bank.com/transfer?to=attacker&amount=1000. If you visit that page while logged into your bank, your browser might automatically send the request with your session cookies, completing the transfer.

To prevent this, modern applications use anti-CSRF tokens. These are unique, unpredictable values that the application server generates for each user session. This token must be included in any sensitive request (like changing an email or transferring funds). An attacker on a different domain can't guess this token, so their forged request will fail.

This is where XSS changes the game. Because your injected JavaScript code runs on the same origin as the target application, it is not bound by the Same-Origin Policy. Your script can:

1. Read the content of any page on that domain.
2. Find the anti-CSRF token, which is often embedded in a hidden form field.
3. Construct a valid request that includes the legitimate token.
4. Send this request to perform a sensitive action (e.g., change the victim's password or email), all without the victim's knowledge.

This is the essence of performing CSRF via XSS. Your script acts as a malicious puppeteer inside the victim's browser.

The Nuharbor Security article "alert('XSS – Pwn3d!'): The Real Dangers of Cross-Site ..." provides a great conceptual overview of this technique.

2. Crafting the Payload: A Practical Walkthrough

Now let's see how this works in practice. The process involves identifying a target action, finding the CSRF token, and scripting the attack.

This video provides an excellent end-to-end demonstration of exploiting a stored XSS to change a victim's email address by bypassing the CSRF token defense.

As you saw, the payload consists of a few logical parts:

1. Get the Token: var token = document.getElementsByName('csrf')[0].value;
2. Prepare the Data: A FormData object is created to hold the parameters for the POST request, including the malicious email and the retrieved token.
3. Send the Request: The fetch() API is used to send the POST request to the /my-account/change-email endpoint with the prepared data in its body.

This all happens silently in the background when the victim loads the page containing your stored XSS payload.

3. Advanced Technique: Chaining XSS with CORS Misconfigurations

You can amplify the impact of XSS by chaining it with other vulnerabilities. A common and powerful chain involves XSS and a Cross-Origin Resource Sharing (CORS) misconfiguration.

Imagine this scenario:

• The main application is at https://api.example.com. It has a sensitive endpoint like /users/delete.
• The developers have misconfigured CORS to trust any subdomain, like *.example.com.
• You find a simple reflected XSS on a forgotten blog at https://blog.example.com.

By itself, the XSS on the blog seems low-impact. But because of the CORS policy, a script running on blog.example.com is trusted to make authenticated requests to api.example.com. You can craft an XSS payload on the blog that, when a logged-in admin visits, sends a DELETE request to the API and deletes their account.

Let's watch a demonstration of this exact scenario.

This type of vulnerability chaining is exactly what separates a good bug hunter from an expert. It requires you to see the system as a whole and connect the dots between lower-severity findings to create a high-impact attack.

4. Hands-on Lab: Perform CSRF via XSS

It's time to put your knowledge into practice. This PortSwigger lab challenges you to do exactly what we've covered: use a stored XSS vulnerability to steal a CSRF token and change a victim's email.

Conclusion

Excellent work! You have now added another powerful technique to your XSS arsenal. You've learned that even when you can't directly steal a user's HttpOnly cookie, you can still achieve account takeover by commanding their browser to perform actions on their behalf.

Key Takeaways:

• XSS Bypasses CSRF Protection: An XSS vulnerability negates the protection offered by anti-CSRF tokens because the malicious script runs on the trusted domain.
• Two-Step Attack Logic: The most common pattern is to first fetch a page to obtain a valid CSRF token and then use that token to forge a second, malicious request.
• The Right Tool for the Job: Modern payloads use the fetch API or XMLHttpRequest to perform these background requests silently.
• Impact through Chaining: Combining XSS with other weaknesses, like a misconfigured CORS policy, can drastically increase the impact of your findings.

Next Lesson Preview:
Today, we focused on using XSS to bypass CSRF defenses. This naturally leads to a deeper look at CSRF itself. In the next lesson, you will learn how to test for Cross-Site Request Forgery (CSRF) vulnerabilities as a standalone issue and analyze the effectiveness of different anti-CSRF tokens. This will round out your understanding of session-related attacks.