Mitigating Cross-Site Request Forgery (CSRF) Attacks

What is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF) is a widely known web security vulnerability that enables a malicious user to induce another user(s)into performing unintended sensitive actions.

If CSRF is exploited successfully, the attacker causes the victim to trigger a sensitive and/or state-changing action unintentionally. They are not just limited to changing the email address on the victim’s account, but also change the victim’s password, and delete the victim’s account.

Image: An example of a CSRF attack’s flow

 

Preconditions for successful Cross-Site Request Forgery (CSRF) attack

• A state-changing action: There is a state-changing action within the target applications that the attacker has reason to exploit. It could be any action specific to the user account (such as changing the user’s password) or a privileged action (like changing permissions for other users).
• Cookie-based session management: It relies only on session cookies to identify the user who has generated the state-changing request. There is no other mechanism for validating user requests.
• Absence of uncertain request parameters: The request that carries out the action does not contain any parameter of values that the attacker can’t guess or determine. If an attacker needs to know the value of the existing password of the victim when attempting to change the victim’s password via a CSRF attack, then the function is not vulnerable.

A typical Cross-Site Request Forgery (CSRF) attack

• The attacker generates a Cross-Site Request Forgery (CSRF) exploits for the vulnerable website and hosts it on a web server under their control.
• If a victim visits the attacker’s web page, the attacker’s malicious website will trigger an HTTP request to the vulnerable website.
• If the user is logged into the vulnerable website, their browser will automatically include their session cookie in the request (unless SameSite cookies are used).
• The vulnerable website will process the request as if the victim made it, and execute the state-changing action,e.g., delete their account.

Image: CSRF exploit PoC

Preventing CSRF attacks with tokens

The most tried and tested way to defend against CSRF attacks is the inclusion of CSRF tokens within state-changing requests. A CRSF token is generally created on the server-side of the application which is a secretive and unique value that is later on transmitted to clients via a subsequent HTTP request created by them. When the latter request is created, the server validates the request that includes the expected token, but it rejects the request if the token is missing or invalid.

The tokens help mitigate CSRF attacks by rendering it impossible for an attacker to forge a valid HTTP request suitable for exploiting the victim. As the attacker is not qualified to predict the value of the other user’s token, they won’t be able to generate a request with the required variable for the target application to receive it.

These tokens are considered sensitive information and are managed securely throughout their life-cycle. The most common approach is to transfer the token to the client that is present in the hidden field of HTML form is by submitted it by POST method. It will then include the token as a request parameter when the form is submitted:

<input type=”hidden” name=”csrf-token” value=”UseinNextRequest_rng123″ />

Image: CSRF token in use

Secure implementation of CSRF tokens has the following properties:

• Highly randomized and unpredictable.
• The token should be mapped to the individual user’s session.
• It should be validated before a relevant or state-changing action is executed.

 

Common flaws in CSRF token implementation

Tokens are not mapped to the user’s session

• Some web applications implement a shared pool of tokens and accept any token that appears in this pool.
• Validation of the applications is necessary as they clarify that that token belongs to the same session as the request has been made by the same user.
• If the tokens are not mapped to the user’s session, the attacker can log in to the application, get a valid token, and pass that token to the victim for exploiting their CSRF.

Image: CSRF token not mapped to a user session

 

Token validation relies on the request method

Consider the following example, where the original request uses the POST method. In this scenario, the server application validates the CSRF token only when the request method is POST.

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

csrftoken=UserA_rng123&email=user_a@nulltest.local

In this situation, the attacker can change the request to GET method, for bypassing the validation and exploit the CSRF attack:

GET /email/change?email=hacked@nulltest.localHTTP/1.1
Host: popular-website.com
Cookie: session= rng456xZ

 

Defense in depth with SameSite cookies

CSRF attacks are centered on exploiting the default browser behavior of including a website’s session cookie(s) in cross-site requests. This allows an attacker to forge HTTP request(s) and induces the victim to trigger a sensitive and/or state-changing action unintentionally.

Most Cross-Site Request Forgery (CSRF) attacks comprise a scenario in which the victim visits the attacker-controlled website and the attacker’s website triggers a state-changing HTTP request to the vulnerable website. How cookies are submitted or whether they are submitted in cross-site requests can be controlled by the SameSiteattribute.

A web application can prevent the default browser behavior of automatically adding cookies to requests by setting the SameSite attribute on session cookies, regardless of the origin of the requests.

The server will issue the cookie when this is included in the Set-Cookie response. Strict or Lax. Are the given two values for the attributes.

Set-Cookie: SessionId=rng_123xD; SameSite=Strict;

Set-Cookie: SessionId= rng_123xD; SameSite=Lax;

The browser will not be including the cookies in any of the requests that are originating from a different site when the setting of the SameSite attribute is Strict. This is the most restrictive option, but it hinders the user experience. The user will not appear to be logged in when the user has used a third-party link to the site and will have to log in again. This scenario occurs when the attribute is set to Strict.

The browser will include cookies in a request that that originates from the other site if the SameSite attribute is configured to Lax, but there are two conditions to be followed:

• The request uses the GET method. Cookies will not be included if other methods are used like POST.
• When a user generates a result from top-level navigation by clicking a link. Also, cookies will not be included when the other requests are generated by scripts.

Using SameSite cookies in Lax mode provides a partial defense against CSRF attacks, considering the hindrance caused because ofStrictSameSite cookies in many scenarios.

Besides CSRF tokens, these cookies act as an additional defense mechanism that might help mitigate any lapse in implementing CSR tokens. However, it is not recommended to rely solely on SameSite cookies as a defense against CSRF attacks.

 

References and further reading

If you would like to delve deeper into this topic, here are a few resources I recommend:

1. https://portswigger.net/web-security/csrf
2. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

 

Author,

Akshay Khilari

Attack & PenTest Team

Varutra Consulting Pvt. Ltd.