SameSite Lax bypass via method override


This lab’s change email function is vulnerable to CSRF.

Reproduction and proof of concept

Study the change email function

  1. In Burp’s browser, log in to the wiener account and change the email address.

  2. In Burp, go to the Proxy -> HTTP history tab.

  3. Study the POST /my-account/change-email request and notice that this doesn’t contain any unpredictable tokens, so it may be vulnerable to CSRF if you can bypass the SameSite cookie restrictions.

  4. Look at the response to the POST /login request. Notice that the website doesn’t explicitly specify any SameSite restrictions when setting session cookies. As a result, the browser will use the default Lax restriction level.

This means the session cookie will be sent in cross-site GET requests, as long as they involve a top-level navigation.

Bypass the SameSite restrictions

  1. Send the POST /my-account/change-email request to Burp Repeater.

  2. In Burp Repeater, right-click on the request and select Change request method. Burp automatically generates an equivalent GET request.

  3. Send the request. The endpoint only allows POST requests.

  4. Try overriding the method by adding the _method parameter to the query string:

GET /my-account/change-email? HTTP/1.1
  1. Send the request. This seems to have been accepted by the server.

  2. In the browser, go to the “MyAccount” page and confirm that the email address has changed.

Craft an exploit

  1. In the browser, go to the exploit server.

  2. In the Body section, create an HTML/JavaScript payload that induces the viewer’s browser to issue the malicious GET request. This must cause a top-level navigation in order for the session cookie to be included:

    document.location = "";
  1. Store and view the exploit yourself. Confirm that this has successfully changed the email address on the target site.


  1. Deliver the exploit to the victim to solve the lab.


An attacker needs to have an account.