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.
Lab: SameSite Lax bypass via method override
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:
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.
Study the change email function
In Burp's browser, log in to your own account and change your email address.
In Burp, go to the Proxy > HTTP history tab.
POST /my-account/change-emailrequest and notice that this doesn't contain any unpredictable tokens, so may be vulnerable to CSRF if you can bypass the SameSite cookie restrictions.
Look at the response to your
POST /loginrequest. Notice that the website doesn't explicitly specify any SameSite restrictions when setting session cookies. As a result, the browser will use the default
Recognize that this means the session cookie will be sent in cross-site
GETrequests, as long as they involve a top-level navigation.
Bypass the SameSite restrictions
POST /my-account/change-emailrequest to Burp Repeater.
In Burp Repeater, right-click on the request and select Change request method. Burp automatically generates an equivalent
Send the request. Observe that the endpoint only allows
Try overriding the method by adding the
_methodparameter to the query string:
GET /my-account/change-email?email=foo%40web-security-academy.net&_method=POST HTTP/1.1
Send the request. Observe that this seems to have been accepted by the server.
In the browser, go to your account page and confirm that your email address has changed.
Craft an exploit
In the browser, go to the exploit server.
GETrequest. Remember that this must cause a top-level navigation in order for the session cookie to be included. The following is one possible approach:
<script> document.location = "https://YOUR-LAB-ID.firstname.lastname@example.org&_method=POST"; </script>
Store and view the exploit yourself. Confirm that this has successfully changed your email address on the target site.
Change the email address in your exploit so that it doesn't match your own.
Deliver the exploit to the victim to solve the lab.