Cross Site Request Forgery

CORS

Introduction

Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.

Impact

In a successful CSRF attack, the attacker causes the victim user to carry out an action unintentionally. For example, this might be to change the email address on their account, to change their password, or to make a funds transfer. Depending on the nature of the action, the attacker might be able to gain full control over the user's account. If the compromised user has a privileged role within the application, then the attacker might be able to take full control of all the application's data and functionality.

How to Test

Cross-site Request Forgery in GET Requests

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

The above is a CSRF attack using an HTTP GET request. If the victim visits a web page controlled by the attacker with the following payload, the browser will send a request containing the cookie to the attacker-crafted URL.

Cross-site Request Forgery in POST Requests

For example, suppose an application contains a function that lets the user change the email address on their account. When a user performs this action, they make an HTTP request like the following

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


email=wiener@normal-user.com

This meets the conditions required for CSRF:

The action of changing the email address on a user's account is of interest to an attacker. Following this action, the attacker will typically be able to trigger a password reset and take full control of the user's account.
The application uses a session cookie to identify which user issued 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 that are needed to perform the action.

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

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

If a victim user visits the attacker's web page, the following will happen:

The attacker's page will trigger an HTTP request to the vulnerable web site.
If the user is logged in to the vulnerable web site, their browser will automatically include their session cookie in the request (assuming Same Site Cookies are not being used).
The vulnerable web site will process the request in the normal way, treat it as having been made by the victim user, and change their email address.

How to Fix

By implementing Anti CSRF tokens we can mitigate the Cross Site Request Forgery Attacks.

How To Generate and Verify Tokens

When you generate and later verify your token, follow these principles to make sure that your anti-CSRF token cannot be guessed or otherwise abused:

Use a non-predictable, well-established random number generator with enough entropy.
Expire tokens after a short amount of time so that they cannot be reused.
Use safe ways to verify whether the received token is the same as the set token, for example, compare hashes.
Do not send tokens in HTTP GET requests so that they are not directly available in the URL and they do not leak in the Referer header.

In PHP you can generate a token as follows:

$_SESSION['token'] = bin2hex(random_bytes(24));

And verify the token as follows:

if (hash_equals($_SESSION['token'], $_POST['token'])) {
  // Action if token is valid
} else {
  // Action if token is invalid
}

In ASP.NET MVC:

To add the anti-forgery tokens to a Razor page, use the HtmlHelper.AntiForgery Token helper method:

@using (Html.BeginForm("Manage", "Account")) {
    @Html.AntiForgeryToken()
}

This method adds the hidden form field and also sets the cookie token.

Anti-CSRF and AJAX

The form token can be a problem for AJAX requests, because an AJAX request might send JSON data, not HTML form data. One solution is to send the tokens in a custom HTTP header. The following code uses Razor syntax to generate the tokens, and then adds the tokens to an AJAX request. The tokens are generated at the server by calling AntiForgery.GetTokens.

In HTML,

<script>
    @functions{
        public string TokenHeaderValue()
        {
            string cookieToken, formToken;
            AntiForgery.GetTokens(null, out cookieToken, out formToken);
            return cookieToken + ":" + formToken;                
        }
    }

    $.ajax("api/values", {
        type: "post",
        contentType: "application/json",
        data: {  }, // JSON data goes here
        dataType: "json",
        headers: {
            'RequestVerificationToken': '@TokenHeaderValue()'
        }
    });
</script>

When you process the request, extract the tokens from the request header. Then call the AntiForgery.Validate method to validate the tokens. The Validate method throws an exception if the tokens are not valid.

In C#,

void ValidateRequestHeader(HttpRequestMessage request)
{
    string cookieToken = "";
    string formToken = "";

    IEnumerable<string> tokenHeaders;
    if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
    {
        string[] tokens = tokenHeaders.First().Split(':');
        if (tokens.Length == 2)
        {
            cookieToken = tokens[0].Trim();
            formToken = tokens[1].Trim();
        }
    }
    AntiForgery.Validate(cookieToken, formToken);
}

References

PreviousBrute Force Attack NextSQL Injection

Last updated 5 years ago

Was this helpful?