Doubt on CSRF exploitation using Client side Redirect when session cookie is set Samesite: Strict

HTB Content Academy
1

ADVANCED XSS AND CSRF EXPLOITATION MODULE

In the section Misc CSRF Exploitation, we discuss the CSRF exploitation if there is a client side redirect, even if the Session cookies are set with Samesite Strict, the cookies will be send with redirect. That makes sense as the application itself makes the redirect to a State changing URL ( endpoint should allow state change through GET request? ).
But my doubt is
Suppose I have a malicious website that has the below script

<script>
document.location = "http://vulnerablesite.htb/admin.php?user=htb-stdnt%26promote=htb-stdnt";
</script>

The working is /admin.php has meta tag which redirects the user to /profile.php + the part you gave inside user parameter so it’ll be
/profile.php?user=htb-stdnt&promote=htb-stdnt
( If successful it’ll promote the user inside promote param as admin )
The application initiates a cross-origin request to /admin.php.
But since cookie is set with Samesite Strict the cookies won’t be sent and it should redirect to /login.php in most case as you are not authenticated.
I get that if you are authenticated, the redirect happens ( vuln app makes it ) so it is samesite so cookies will be send to /profile.php. But at the first place the first request which is to /admin.php, cookies are not send so it should redirect to login.php.

2

Good question! In many cases, you would be correct. If the initial cross-site request is to an authenticated endpoint, then the cookie will not be sent. However, in the lab challenge for that section, you may notice that /admin.php can actually be accessed without logging in. So, there is no need for the cookie to be sent with that request. The section doesn’t explain this very well, and it makes sense to assume that an endpoint with the name “admin” would be authenticated, so the confusion is definitely understandable.

1 Like