🔓 Free Link

Table of Contents

  1. Summary of the Vulnerability
  2. Proof of Concept (PoC)
  3. Impact

Summary of the Vulnerability

This lab demonstrates a CSRF vulnerability in an email change feature that relies on SameSite=Lax cookies as the primary defense mechanism. The application assumes that the browser will not send session cookies during cross-site requests, preventing unauthorized actions. However, this assumption becomes incorrect when the request method can be manipulated using a method override parameter.

After logging in with the provided credentials (wiener:peter), the email change functionality can be observed sending a POST request containing the new email address. When this request is intercepted in Burp Suite and replayed as a GET request, the server rejects it with a Method Not Allowed response, confirming that the endpoint is intended to accept only POST.

The key weakness appears when the application supports method overriding using the _method parameter. The server processes the request as if it were a legitimate POST, while the browser still treats it as a top-level navigation GET request. Because SameSite=Lax allows cookies to be sent on top-level GET requests, the victim's session cookie is included, making the request authenticated.

When the victim visits the exploit page, the browser sends the request as a GET navigation, cookies are included due to SameSite=Lax rules, and the server interprets the request as POST because of the override parameter. As a result, the victim's email address is changed without their consent.

Proof of Concept (PoC)

Steps to Reproduce

  • Open the lab and log in using the provided credentials: wiener:peter.
  • After logging in, navigate to the account page and try changing the email address for the wiener user to any random value to observe how the request is sent.
Image 1 – 3daa328b0ee6
  • Open Burp Suite → HTTP history, locate the request responsible for the email change:
POST /my-account/change-email
  • Right-click the request and send it to Repeater.
  • Generate a CSRF proof-of-concept by right-clicking the request in Repeater and selecting:
Engagement tools → Generate CSRF PoC

Available in Burp Suite Professional

Image 2 — 3daa328b0ee6
  • A popup window will appear containing the generated HTML form. Modify the email parameter to a custom value, for example:
evil@portswigger.net
Image 3 — 3daa328b0ee6
  • Copy the generated CSRF PoC and paste it into the Exploit Server, then click:
Store → Deliver exploit to victim
Image 4 — 3daa328b0ee6
  • Wait a few seconds and observe that nothing happens.
  • When selecting View exploit, the browser is redirected to the login page, which indicates that the attack failed.
  • Go back to Repeater and change the request method from POST → GET
  • The server responds with Method Not Allowed.
Image 5 — 3daa328b0ee6
  • This confirms that the endpoint only accepts POST requests, so a direct GET-based CSRF will not work.
  • According to the behavior described in the PortSwigger material, the application supports method override, which allows the HTTP method to be controlled using a parameter.
Image 6 — 3daa328b0ee6
  • Generate a final CSRF PoC:
<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://LAB-ID.web-security-academy.net/my-account/change-email">
      <input type="hidden" name="_method" value="POST">
      <input type="hidden" name="email" value="takeover@portswigger.net" />
      <input type="submit" value="Submit request">
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>
Image 7 — 3daa328b0ee6
  • This works because:
- The browser sends the request as GET
- SameSite=Lax allows cookies on top-level GET navigation
- The server interprets the request as POST because of _method=POST
  • Paste the updated payload into the Exploit Server, then click:
Store → Deliver exploit to victim
Image 8 — 3daa328b0ee6
  • After a few seconds, the lab is marked as solved, indicating that the victim visited the exploit page and the CSRF attack successfully changed the email address.
Image 9 — 3daa328b0ee6
  • You can also verify the attack in the Exploit Server access log, where the victim's request to the exploit page is recorded.
Image 10 — 3daa328b0ee6

Impact

In production systems, this type of flaw can lead to unauthorized state-changing actions being executed on behalf of authenticated users, even when SameSite cookies are enabled.

If exploited in a real application, an attacker could:

  • Change account email addresses
  • Modify profile data
  • Trigger password reset flows

📢 Enjoyed this post? Stay connected! If you found this article helpful or insightful, consider following me for more:

🙏Your support is appreciated.

Latest Cybersecurity News, Vulnerabilities, and Technical Analysis

Stay updated with the latest cybersecurity news, discover vulnerabilities, and explore technical analysis in our lab…

bashoverflow.com