What is Cross-Site Request Forgery?

Overview

A cross-site request forgery (CSRF) attempts to execute an action rather than trying to steal personal data. Once an attack is executed there is no way for the attacker to directly monitor the result so attackers often execute multiple forgeries.

The attack can come from malicious emails, websites, or blogs, and targets another open website that a user has already logged into. When a basic user is targeted, the goal for the attacker is usually changing a password or transferring currency. When an administrative user is targeted, a successful CSRF attack can compromise an entire web application.

How to Defend Against CSRF

1. Implement Header Checks
   A majority of requests will include an origin header and/or a reference header. Without a cross-site scripting vulnerability these are extremely difficult to spoof. Ensuring the origin header does in fact match the origin site is a quick and simple first step, but this is not enough of a defense on its own.
2. Use a Double Submit Cookie
   When a user logs in to a web application the site generates a random value and sets it as a cookie. A double submit cookie sends this value as a cookie but also as a request parameter. The server then confirms that the cookie value and the request parameter value match before executing a transaction request. An attacker can not change a cookie value with a CSRF attack, so even if the request parameter is manipulated the malicious request will not execute.
3. Implement Synchronizer Tokens
   Synchronizer tokens are often referred to as “challenge” tokens. These challenge tokens are included within an HTML form and associated with sensitive server-side tasks. When a user wants to execute a sensitive operation the request needs to include the challenge token.On the server side, the web application verifies that the request includes the token. If it does not, the server rejects the request. Note that this method does require a server side state to be stored and quickly accessible. It is currently considered the best way to prevent CSRF attacks.

Example of CSRF

Assume you are banking with BigBank. You want to check your balance so you log in to your account at BigBank.com. During the process of checking your balance you decide to check something urgent on DangerousWebsite.com. Malicious attackers have added the following line of code on DangerousWebsite.com

<iframe src="http://bigbank.com/app/transferFunds?amount=5000&destinationAccount=... >

When you visit the malicious website a CSRF attack is carried out against BigBank.com and 5,000 dollars is stolen from your account. The attack could have been prevented through the use of synchronizer tokens or double submit cookies. It could also have been prevented by only having one window open when performing sensitive actions and remembering to log out at the end of a session.

Conclusion

CSRF attacks are a serious issue that can cost a company a significant amount of resources. Having to sort through customers that have undergone attacks takes time and issuing refunds for the actions of malicious attackers equates to lost profits.

In 2014 a study by WhiteHat concluded that it took over 100 days to resolve issues that arose from CSRF across almost all programming languages. Implementing CSRF preventive security measures from the beginning saves both time and money in the long run.