SameSite Lax bypass via method override

TL;DR

No csrf token is present on update mail POST request. Changing the method to GET returns a 405 Method not allowed that prevents us to trigger a simple CSRF. Leverage the _method parameter from the framework to override the server method interpretation while keeping the HTTP GET method intact, allowing the victim’s browser to send session cookie along the request.

Learning Material

---

In practice, servers aren’t always fussy about whether they receive a GET or POST request to a given endpoint, even those that are expecting a form submission. If they also use Lax restrictions for their session cookies, either explicitly or due to the browser default, you may still be able to perform a CSRF attack by eliciting a GET request from the victim’s browser.

As long as the request involves a top-level navigation, the browser will still include the victim’s session cookie. The following is one of the simplest approaches to launching such an attack:

<script> document.location = 'https://vulnerable-website.com/account/transfer-payment?recipient=hacker&amount=1000000'; 
</script>

Even if an ordinary GET request isn’t allowed, some frameworks provide ways of overriding the method specified in the request line. For example, Symfony supports the _method parameter in forms, which takes precedence over the normal method for routing purposes:

<form action="https://vulnerable-website.com/account/transfer-payment" method="POST">
	<input type="hidden" name="_method" value="GET"> <input type="hidden" name="recipient" value="hacker">
	<input type="hidden" name="amount" value="1000000">
</form>

Other frameworks support a variety of similar parameters.

Lab

---

This lab’s change email function is vulnerable to CSRF. To solve the lab, perform a CSRF attack that changes the victim’s email address. You should use the provided exploit server to host your attack.

You can log in to your own account using the following credentials: wiener:peter

Note

The default SameSite restrictions differ between browsers. As the victim uses Chrome, we recommend also using Chrome (or Burp’s built-in Chromium browser) to test your exploit.

Actually I do use Firefox anyway.

Hint

You cannot register an email address that is already taken by another user. If you change your own email address while testing your exploit, make sure you use a different email address for the final exploit you deliver to the victim.

Write-up

---

As usual from previous labs, login and check the change mail feature.

Note that no csrf token is used. Quick check on cookie session value shows us the Samesite wasn’t set, so it’s Lax by default on Chrome and Firefox (and most browsers).

This means if we successfully trigger a GET request with “top-level navigation”, the target session cookies will be used for the exploit. We can try to simply change the method and insert our parameter in the URL though it gets refused :

If we learned something from the learning material instead of going blind, we should try to leverage the _method=POST parameter to indicate the server which method should be interpreted. This will still be considered as a GET request from the browser and is the key to this vulnerability since the browser looks up at the HTTP Method to evaluate the appropriate behaviour.

Now we are able to craft a payload that contains this exact URL and deliver it. This should bypass the samesite lax value.

<script> document.location = 'https://0a0a00bb03ead414802c0dfe0067008b.web-security-academy.net/my-account/change-email?email=adios%40carlos&_method=POST'; 
</script>

This solves the lab.