< Back





8. SameSite Strict bypass via client-side redirect

This website sends us a cookie with the SameSite=Strict attribute. This attribute prevents the
browser from sending the cookie in a cross-site request. We use a gadget to get the browser to
conduct a client-side redirect to execute our CSRF attack.

What's a client-side redirect? It's usually a redirect that happens in the browser via JavaScript,
rather than the server processing the input and sending a 302 response. Client-side redirects are
necessary to bypass SameSite=Strict restrictions, because server-side redirects are still related
to the cross-site nature of the original CSRF attack. If we can get the browser to do a client-side
redirect, the browser will trust the request and send the cookie.

We discover that /post/comment/confirmation requests a script that reads the postId parameter and
joins the basename of the website and the postId parameter to create a new URL - no checking of the
postId parameter is conducted. After this new endpoint is constructed the script redirects the user
to the newly constructed URL.

We abuse this code to conduct a Local File Inclusion (LFI), sending the user to the
/my-account/change-email endpoint, passing the parameters of the new email, and the submit parameter
required by the API. The victim visits our exploit server, makes a GET request to this crafted URL,
travels to /post/comment/confirmation and then is redirected to /my-account/change-email.


Solution