Skip to content

Cross-Site Request Forgery (CSRF)

A CSRF attack takes place when an attacker crafts a malicious web request and tricks the victim into sending the request to a web application that they are already authenticated to. The malicious web request could do anything such as transfer funds, change account information, or any other action an authenticated user could make on the web application. A website is vulnerable to CSRF attacks if it only uses cookies to validate whether a web request is coming from an authenticated user.

CSRF Tokens

CSRF Tokens can be used to guard against CSRF attacks. A CSRF token is a long random string that is provided by the webserver to the user which is used to prove that they are authenticated. A CSRF token differs from a cookie because it is sent in a different field of the web request. Even though a CSRF token might be stored in the same location as cookies a CSRF attack will not be able to take the value of the CSRF token and place it in the required field of the web request that is required to prove that the request is coming from an authenticated user.

  • Custom headers typically cannot be set in CSRF attacks. See: http://blog.alutam.com/2011/09/14/jersey-and-cross-site-request-forgery-csrf/
  • Custom headers may be sufficient to stop current CSRF attacks. However, random generated CSRF tokens are smart to use in preparation for if attackers figure out how to set customer headers.

Protections against CSRF

Synchronizer Token Pattern

  • A new CSRF token is generated for each form submission or per session.
  • Generating tokens per form submission can cause issues in scenarios such as using the "back" button on the browser, since the CSRF token on the previous page will no longer match what it used to.

Double submit cookies

  • Weaker CSRF protection
  • The server provides a random value as a cookie and the user must submit this cookie value both as a cookie and in a customer header when making web requests.
  • If this flag is set then it can stop cookies from being sent cross-site which are the basis behind CSRF attacks.
  • A browser might not support this feature.
  • Lacks the ability for fine-grain control. Example: The website (example.com) is a forum and someone posts a link to the forum's delete account function (example.com/DeleteAccount). Any user who clicks this link will send their cookies. If aditional protections such as a CSRF token is not also implemented then the delete account function would execute.

Challenge/response pattern

When submitting a web request (such as transferring funds) the server should have a challenge such as asking for a password in order to authenticate the web request. A CSRF attack should not be able to know what the answer to the challenge is, therefore a CSRF will not work.

Origin and Referer Headers

  • Verify that the web request destination origin is something the web application expects.
  • The Origin and Referer headers can only be set by the browser.

Examples: - Legitimate request - submitting a fund transfer on bank.com would show the request originated from bank.com - Forged request - visting evil.com triggers a CSRF attack to transfer funds on bank.com The request would show originating from evil.com.

This protection can cause issues in scenarios where the origin header is altered for legitimate reasons such as using adblocker.