What is CSRF (Cross-Site Request Forgery) attack and how it works?

Page Contents

Cross-Site Request Forgery (CSRF) is a type of web security vulnerability that allows an attacker to carry out unauthorized actions on behalf of a victim user by exploiting the trust relationship between a user and a website. CSRF attacks typically occur when a user is logged in to a website and the attacker tricks the user into clicking a malicious link or visiting a malicious website.

What is a real world example of a CSRF attack?

Here is an example of a CSRF attack code that targets a simple web application that allows changing a user’s email address through a HTTP GET request:

<html>
  <body>
    <h1>Change Email Address</h1>
    <form action="http://example.com/update_email" method="get">
      <input type="hidden" name="email" value="attacker@example.com" />
      <input type="submit" value="Change Email" />
    </form>
  </body>
</html>

In this example, the attacker creates a malicious website that includes a form that targets the vulnerable web application at http://example.com/update_email. The form includes a hidden input field named “email” that contains the attacker’s email address, which will be submitted as the new email address for the victim user.

When the victim visits the malicious website and clicks the “Change Email” button, their web browser sends a GET request to the vulnerable web application with the attacker’s email address as a parameter. Because the request appears to come from the victim user, the web application assumes that it is legitimate and updates the user’s email address to the attacker’s email address.

CSRF Attack Example to Steal Session Cookies

Here’s an example of a CSRF attack code that targets a website to steal session cookies:

<html>
  <body>
    <h1>Click to View Cute Kittens!</h1>
    <img src="http://www.example.com/cute-kittens.jpg" width="300" height="200" />
    <form action="http://www.example.com/logout" method="GET" id="logout-form">
      <input type="submit" value="Logout" />
    </form>
    <script>
      // This script will automatically submit the logout form to steal the user's session cookies
      // when the user clicks the "View Kittens" link
      window.onload = function() {
        var form = document.getElementById('logout-form');
        form.submit();
      }
    </script>
  </body>
</html>

In this above mentioned example of CSRF attack to steal web application session cookies, the attacker creates a fake website that includes a link to view cute kittens, but also includes a hidden form that logs the user out of the target website when the page loads. When the user clicks the link, the JavaScript code automatically submits the logout form, which steals the user’s session cookies and sends them to the attacker’s server.

7 CSRF Attack Prevention and Mitigation Techniques to secure applications vulnerabilities

Token Synchronization
Double-Submitting Cookies
Same-Site Cookies
Enabling User Interaction
Custom Headers for Requests
Use of Captcha
Use Referer header

CSRF Mitigation Technique #1: Token Synchronization

Token Synchronization is a CSRF attack mitigation technique that involves generating and validating a unique token for each user session to prevent unauthorized requests. The token is typically included in a hidden form field or in a custom HTTP header, and is verified by the server before processing the request.

How Token Synchronization works to mitigate CSRF attacks?

Token synchronization is a technique used to prevent CSRF attacks by adding an extra token to each form that is submitted. This token is then checked by the server to ensure that the request was generated by the same user who originally requested the form.

Here’s how token synchronization works:

When a user requests a form, the server generates a random token and includes it in the form as a hidden input field.
When the user submits the form, the server checks that the token included in the request matches the token that was originally generated for the form. If the tokens match, the server accepts the request as legitimate and processes it. If the tokens do not match, the server rejects the request.
When the server sends a response to the user, it includes a new random token that will be used for the next request.

Token Synchronization is effective in mitigating CSRF attacks because it ensures that requests can only be made from a valid user session. This means that even if an attacker can generate a request that looks like it comes from the user, they will not have the correct token and the request will be rejected. By using token synchronization, the server can ensure that a request came from an authenticated user and was not generated by an attacker. The attacker cannot predict or guess the correct value of the token since it is generated randomly for each form.

Generates Unique Token

When the user logs in to a website, a unique token is generated for their session.

Custom HTTP Header

The token is included in any forms or requests sent by the user, either as a hidden field or in a custom HTTP header.

Token Match

When the server receives the request, it checks that the token matches the one generated for the user’s session.

Check and Validate Token

If the token is valid, the server processes the request as normal. If the token is invalid or missing, the server rejects the request and does not perform the action.

One of the benefits of Token Synchronization is that it is a relatively simple mitigation technique to implement. However, it does require developers to modify their applications to generate and validate tokens for each user session. Additionally, if tokens are not properly synchronized or are easily guessable, they can be vulnerable to brute-force attacks. Therefore, it is important for developers to properly design and test their token synchronization implementation to ensure its effectiveness in mitigating CSRF attacks.

CSRF Mitigation Technique #2: Double-Submitting Cookies

Double-Submit Cookies is a technique used to mitigate CSRF attacks by creating and validating two cookies with the same value but different names.

How Double-Submitting Cookies mitigate CSRF attack?

Here’s how Double-Submit Cookies work to mitigate and prevent CSRF attack:

When the user logs in, the server generates a session ID and sets two cookies:
- “sessionID” cookie contains the session ID.
- “csrfToken” cookie contains a random token, such as “ABCDE12345”.
When the user submits a form, the server checks that the values of both cookies match. For example, the form might contain the following hidden input fields:

<form method="post" action="/submit-form">
  <input type="hidden" name="csrfToken" value="ABCDE12345">
  <input type="hidden" name="data" value="some data">
  <input type="submit" value="Submit">
</form>

When the server receives the request, it checks that the “csrfToken” value in the request matches the “csrfToken” value in the cookie. If the values match, the server accepts the request as legitimate and processes it. If the values do not match, the server rejects the request.

When the server sends a response to the user, it includes new values for both cookies, so that the next request will include updated values. For example:

Set-Cookie: sessionID=12345; Path=/
Set-Cookie: csrfToken=FGHIJ67890; Path=/

This ensures that the values of the cookies change with each request, making it difficult for an attacker to guess or predict the correct values.

By using Double-Submit Cookies, the server can validate that a request came from an authenticated user and was not generated by an attacker. The attacker cannot set the values of both cookies to the correct values since they cannot access or modify the legitimate “csrfToken” cookie.

CSRF Mitigation Technique #3: Same-Site Cookies

Same-Site Cookies is a CSRF (Cross-Site Request Forgery) mitigation technique that enhances the security of cookies by preventing them from being sent along with cross-site requests. This helps mitigate CSRF attacks by ensuring that cookies containing sensitive information, such as session identifiers, are not leaked to unauthorized third-party websites.

Working of Same-Site Cookies

Same-Site Cookies introduce a new attribute called “SameSite” in the “Set-Cookie” HTTP header. This attribute has three possible values: “Strict”, “Lax”, and “None”.

Strict: When the SameSite attribute is set to “Strict”, the browser only sends the cookie along with same-site requests (i.e., requests originating from the same domain as the target domain). This means that the cookie will not be sent for any cross-site requests, thereby mitigating the risk of CSRF attacks. However, this may also limit the usability of the website for legitimate cross-site scenarios (e.g., when navigating from an external link).
Lax: When the SameSite attribute is set to “Lax”, the browser sends the cookie along with same-site requests and “safe” cross-site requests, such as GET requests. This provides a balance between security and usability, allowing certain cross-site interactions while still mitigating CSRF attacks.
None: When the SameSite attribute is set to “None”, the browser sends the cookie along with all requests, regardless of whether they are same-site or cross-site. This option effectively disables the SameSite protection and should be used only when necessary for specific use cases.

How Same-Site Cookies mitigate CSRF attack?

The Same-Site Cookies CSRF mitigation technique aims to enhance the security of cookies by controlling when they are sent along with cross-site requests. This helps prevent CSRF attacks by ensuring sensitive information, such as session identifiers, is not leaked to unauthorized third-party websites.

Here’s a step-by-step explanation of how the Same-Site Cookies technique works:

Step 1: Set the SameSite attribute in the “Set-Cookie” HTTP header

When a server sends a cookie to the client, it uses the “Set-Cookie” HTTP header. To apply the Same-Site Cookies mitigation technique, the server must include the “SameSite” attribute in this header, with one of three possible values: “Strict”, “Lax”, or “None”.

Step 2: Configure the appropriate SameSite attribute value

Choose the appropriate value for the SameSite attribute based on the desired balance between security and usability:

“Strict“: The cookie will only be sent along with same-site requests. This provides the highest level of security but may limit the usability of the website for legitimate cross-site scenarios.
“Lax“: The cookie will be sent along with same-site requests and “safe” cross-site requests, such as GET requests. This offers a balance between security and usability, allowing certain cross-site interactions while still mitigating CSRF attacks.
“None“: The cookie will be sent along with all requests, regardless of whether they are same-site or cross-site. This option effectively disables the SameSite protection and should be used only when necessary for specific use cases.

Step 3: Browser handles cookie based on SameSite attribute value

When the client (browser) receives the cookie with the SameSite attribute, it processes the cookie according to the specified attribute value:

If the SameSite attribute is set to “Strict” or “Lax”, the browser will only send the cookie along with requests that meet the specified conditions (same-site or “safe” cross-site requests).
If the SameSite attribute is set to “None”, the browser will send the cookie along with all requests, including cross-site requests.

Step 4: CSRF attack prevention

By limiting when the cookie is sent with cross-site requests, the Same-Site Cookies technique prevents CSRF attacks that rely on the user’s session cookie to authenticate the request. As the attacker’s site cannot include the necessary authentication information in the cross-site request, unauthorized actions on the user’s behalf will fail.

CSRF Mitigation Technique #4: Enabling User Interaction

CSRF Mitigation Technique #5: Custom Headers for Requests

What is CSRF protection?

CSRF protection refers to the security measures implemented to prevent Cross-Site Request Forgery (CSRF) attacks. A CSRF attack occurs when an attacker tricks a user’s browser into performing actions on a website without the user’s consent, typically by leveraging the user’s session cookie to authenticate the request.
CSRF protection aims to ensure that requests made to a web application are genuine and originate from authorized users. Several mitigation techniques can be employed to protect against CSRF attacks, including:
Synchronizer Token Pattern: This technique involves generating a unique token, typically a cryptographically secure random string, which is associated with the user’s session. The token is embedded in web forms or added to URLs as a query parameter, and the server checks the token’s validity upon receiving a request. If the token is missing or does not match the expected value, the request is considered fraudulent and rejected.
Same-Site Cookies: By setting the SameSite attribute in the “Set-Cookie” HTTP header, this technique controls when cookies are sent along with cross-site requests. This helps prevent sensitive information, such as session identifiers, from being leaked to unauthorized third-party websites, thereby mitigating CSRF attacks.
Double Submit Cookies: In this approach, a random value is stored in both a cookie and a hidden form field when a form is rendered. When the form is submitted, the server checks if the values from the cookie and the form field match. If they don’t match or either value is missing, the request is considered fraudulent and rejected.
Referer and Origin Header Validation: This technique checks the “Referer” or “Origin” headers of incoming HTTP requests to verify that they originate from a trusted source. If the headers are missing or do not match the expected domain, the request is considered fraudulent and rejected.
CSRF protection is crucial for maintaining the security and integrity of web applications, as it helps prevent unauthorized actions from being performed on behalf of unsuspecting users.

CSRF mitigation Techniques