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 Strict bypass via client-side redirect
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:
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 any SameSite cookie restrictions.
Look at the response to your
POST /loginrequest. Notice that the website explicitly specifies
SameSite=Strictwhen setting session cookies. This prevents the browser from including these cookies in cross-site requests.
Identify a suitable gadget
In the browser, go to one of the blog posts and post an arbitrary comment. Observe that you're initially sent to a confirmation page at
/post/comment/confirmation?postId=xbut, after a few seconds, you're taken back to the blog post.
postIdquery parameter to dynamically construct the path for the client-side redirect.
In the proxy history, right-click on the
GET /post/comment/confirmation?postId=xrequest and select Copy URL.
In the browser, visit this URL, but change the
postIdparameter to an arbitrary string.
Try injecting a path traversal sequence so that the dynamically constructed redirect URL will point to your account page:
Observe that the browser normalizes this URL and successfully takes you to your account page. This confirms that you can use the
postIdparameter to elicit a
GETrequest for an arbitrary endpoint on the target site.
Bypass the SameSite restrictions
In the browser, go to the exploit server and create a script that induces the viewer's browser to send the
GETrequest you just tested. The following is one possible approach:
<script> document.location = "https://YOUR-LAB-ID.web-security-academy.net/post/comment/confirmation?postId=../my-account"; </script>
Store and view the exploit yourself.
Observe that when the client-side redirect takes place, you still end up on your logged-in account page. This confirms that the browser included your authenticated session cookie in the second request, even though the initial comment-submission request was initiated from an arbitrary external site.
Craft an exploit
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 allows you to change your email address using a
Go back to the exploit server and change the
postIdparameter in your exploit so that the redirect causes the browser to send the equivalent
GETrequest for changing your email address:
<script> document.location = "https://YOUR-LAB-ID.web-security-academy.net/post/comment/confirmation?postId=1/../../my-account/change-email?email=pwned%40web-security-academy.net%26submit=1"; </script>
Note that you need to include the
submitparameter and URL encode the ampersand delimiter to avoid breaking out of the
postIdparameter in the initial setup request.
Test the exploit on yourself and confirm that you have successfully changed your email address.
Change the email address in your exploit so that it doesn't match your own.
Deliver the exploit to the victim. After a few seconds, the lab is solved.