Cross-site request forgery (CSRF)

Context

Cross-site request forgery (CSRF) or XSRF is a web security vulnerability that enables an attacker to manipulate a user into executing unintended actions within an application. This attack partially bypasses the same-origin policy, which safeguards websites from interfering with each other.

In a CSRF attack, the attacker forces the user to carry out an action unwittingly, such as changing the user's email address or password, or initiating a funds transfer. Depending on the attack's nature, the attacker could gain full control over the user's account, data, and functionality if the compromised user has a privileged role within the application.

Three critical conditions are necessary for a CSRF attack to be successful:

First, there must be a relevant action within the application that the attacker wants to induce, such as modifying another user's permissions or altering user-specific data.

Second, the execution of the action relies solely on session cookies to identify the user making the request, without any other mechanism for session management or user request validation.

Lastly, the requests carrying out the action must not contain any parameters whose values the attacker cannot guess or determine.

For instance, suppose an application allows a user to modify their account's email address by sending an HTTP request. In that case, a CSRF attack can manipulate the user into changing their email address to an email address specified by the attacker.

 POST /email/change HTTP/1.1
Host: website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5fsdfqsdlyxHfsAfE

email=wiener@user.com

This meets the requirements for CSRF:

The action of changing an email address on a user's account is of interest to an attacker. Following this action, the attacker can typically trigger a password reset and take full control of the user's account. The application uses a session cookie to identify the user who made the request. There are no other tokens or mechanisms in place to track user sessions. The attacker can easily determine the values of the request parameters needed to perform the action.

With these conditions in place, the attacker can construct a web page containing the following HTML code:

 <html>
    <body>
        <form action="https://website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@attacker-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

If a victim user visits the attacker's webpage, certain actions will be initiated. Firstly, the attacker's webpage will generate an HTTP request to the vulnerable website. If the user happens to be logged in to the vulnerable website, their session cookie will be automatically included in the request (in cases where SameSite cookies are not utilized). Subsequently, the vulnerable website will treat the request as if it was made by the victim user and will execute the necessary modifications on their email address.

How to construct a CSRF attack

The techniques used to launch cross-site request forgery (CSRF) attacks are comparable to those employed for reflected cross-site scripting (XSS) attacks. The attacker typically embeds malevolent HTML code on a website under their control and persuades victims to visit that website. This could be done by sending the user a link to the website through email or social media. Alternatively, if the attack is placed on a popular website, such as in a user comment section, the attacker can patiently wait for users to visit the website.

It should be noted that some CSRF attacks exploit the GET method and can be completely self-contained with a single URL on the vulnerable website. In such cases, the attacker may not need an external website and can directly provide the victim with a malicious URL on the vulnerable domain. For instance, if the email modification request can be made via the GET method, a self-contained attack would appear as follows:

 <img src="https://website.com/email/change?email=pwned@attacker-user.net">

Preventing CSRF attacks

The most effective defense against cross-site request forgery (CSRF) attacks is to incorporate a CSRF token in relevant requests. This token should have a high entropy and be unpredictable, similar to session tokens. It must also be tied to the user's session and should be rigorously validated before any related action is executed.

In addition to CSRF tokens, SameSite cookies can offer an extra line of defense against CSRF, but their effectiveness may be partial. It is therefore recommended to utilize SameSite cookies along with CSRF tokens to ensure better security against CSRF attacks.

Common CSRF vulnerabilities

The most notable vulnerabilities associated with cross-site request forgery (CSRF) arise due to errors made while validating CSRF tokens.

Continuing with the previous example, let's suppose that the application has now added a CSRF token in the request to alter the user's email address:

 POST /email/change HTTP/1.1
Host: website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLn

csrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=wiener@user.com

The addition of a CSRF token to the request should provide protection against CSRF attacks as it eliminates the necessary conditions for a CSRF vulnerability. This implies that the application is no longer solely reliant on cookies for session management and the request carries a parameter whose value is beyond the control of an attacker. Nevertheless, the CSRF defense can be compromised in several ways, leaving the application vulnerable to CSRF attacks.

For example, certain applications may correctly validate the token only when the request employs the POST method but ignore the validation when the GET method is used. In such a scenario, an attacker could switch to the GET method to evade validation and execute a CSRF attack:

 GET /email/change?email=pwned@attacker-user.net HTTP/1.1
Host: website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLn

Certain applications validate the token accurately when it is included in the request, but neglect to validate it if the token is absent. This provides an opening for attackers to remove the entire parameter that contains the token (and not only its value), thereby circumventing validation and conducting a CSRF attack:

 POST /email/change HTTP/1.1
Host: website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLn

email=pwned@attacker-user.net

Certain applications fail to verify that the token corresponds to the same session as the user submitting the request. Instead, the application maintains a global collection of tokens that it has issued and accepts any token that appears in this pool. In such a scenario, an attacker could log in to the application using their account, retrieve a valid token, and then transmit that token to the victim user during the CSRF attack.

In a variation of the aforementioned vulnerability, certain applications link the CSRF token to a cookie that differs from the one utilized to track sessions. This often occurs when an application employs two distinct frameworks, one for CSRF protection and the other for session management, that are not integrated with one another:

 POST /email/change HTTP/1.1
Host: website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXNP; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv

csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tW&email=wiener@user.com

This situation is more complex to exploit, but still presents a vulnerability. If the website features an element that enables an attacker to place a cookie in a victim's browser, then an attack can be initiated. The attacker can log in to the application using their own account, acquire a valid token and its associated cookie, exploit cookie configuration behavior to place their cookie in the victim's browser, and furnish their token to the victim during the CSRF attack.

In another variation of the aforementioned vulnerability, certain applications do not maintain any server-side record of issued tokens. Instead, they replicate each token in both a cookie and a query parameter. During the subsequent validation of a request, the application only checks whether the token submitted in the query parameter corresponds to the value provided in the cookie. This defense against CSRF is sometimes referred to as "double submission" and is promoted because it is simple to implement and eliminates the need for server-side state:

 POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjySz; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpb

csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpb&email=wiener@user.com

In this case, an attacker can once again execute a CSRF attack, provided that the website has a cookie configuration element. Here, the attacker is not required to obtain a valid token themselves. Instead, they can fabricate a token (possibly in the requisite format, if verified), use cookie configuration behavior to insert their cookie in the victim's browser, and provide their token to the victim during the CSRF attack.

Referrer-based Defenses against CSRF

Aside from CSRF token-based defenses, some applications employ the HTTP Referer header to attempt to guard against CSRF attacks, often by confirming that the request originates from their own domain. This approach is typically less effective and frequently vulnerable to evasion.

The effectiveness of Referer validation hinges on the existence of the header. In such a situation, an attacker can engineer their CSRF exploit in such a manner that the victim user's browser eliminates the Referer header from the resulting request. Multiple methods can accomplish this, but the easiest is to employ a META tag in the HTML page hosting the CSRF attack:

 <meta name="referrer" content="never">

If an application validates that the domain initiating the Referer matches the anticipated value, Referer validation can be circumvented. In such a scenario, the attacker can establish it as a subdomain of their domain:

 http://website.com.attacker-website.com/csrf-attack