Cross-Site Forgery

Cross-Site Request Forgery (CSRF)?

A cross-site request forgery attack is a type of confused deputy* cyberattack that tricks a user into accidentally using their credentials to invoke a state-changing activity, such as transferring funds from their account, changing their email address and password, or some other undesired action.

While the potential impact against a regular user is substantial, a successful CSRF attack against an administrative account can compromise an entire server, potentially resulting in a complete takeover of a web application, API, or other services.

How does Cross-Site Request Forgery Work?

This attack focuses on targeting state-changing requests, which refers to the type of request that results in data being changed from one value to another. For example, a targeted request might make a purchase or change a value in an account. Interestingly, this is a “blind attack”, and does not return data to the attacker, making it a poor choice for data theft.

Here is an example of the 4 steps in a cross-site request forgery attack:

1. An attacker creates a forged request that, when it is run, it will transfer $10,000.00 from a particular bank into the attacker’s bank account.
2. The attacker embeds the forged request into a hyperlink and sends it out in bulk emails and also embeds it into websites.
3. A victim clicks on an email or website link placed by the attacker, resulting in the victim making a request to the bank to transfer $10,000.00 to the attacker.
4. The bank server receives the request, and because the victim is properly authorized, it treats the request as legitimate and transfers the funds.

A Forged Request

CSRF attacks vary in methodology, but typically they all have the following characteristics:

• They exploit websites that rely on a user’s identity
• They trick the user’s browser into sending HTTP requests to the targeted site
• They involve using HTTP requests that have side effects and do not have the proper CSRF protections in place

Different HTTP verbs have different vulnerabilities to CSRF attacks, resulting in variable protection strategies. This is due to the way that web browsers handle verbs differently.

HTTP GET requests have embedded parameters, such as those inside image tags, which can be manipulated and exploited. Typically, GET requests do not modify state, making them ineffective as targets of CSRF for a properly implemented web application or other resources.

HTTP POST is used to change state, resulting in an increased need for protection. To this end, web browsers implement security measures called the Same-Origin Policy (SOP) and Cross-Origin Resource Sharing (CORS) which contains the cross-origin security policy. SOP allows only requests from the same origin and CORS allows only certain types of requests to come from a different origin. The combination of these implementations helps to prevent CSRF attacks (among others) by limiting the ability of a request or webpage to interact with a different origin.

Other HTTP verbs such as PUT and DELETE, can only be run using SOP and CORS, mitigating many cross-site attacks.

Though it’s uncommon, some websites will explicitly disable these security measures, and it’s possible to disable them inside of a web browser as well.

How can Cross-Site Request Forgery be mitigated?

The most common methodology for mitigating CSRF attacks involves using Anti-CSRF tokens using one of two methods. While the token implementations are slightly different, the underlying principle remains the same; by creating and then comparing a randomly generated token string, an attacker is less likely to be able to perform an attack without an exceptionally unlikely guess.

Synchronizer token pattern:

When a user visits a web page, such as the bank webpage that allows for the transfer of funds, the bank’s website embeds a random token into the form. When the user submits the form, the random token is returned and the bank is able to check to see if the two tokens match. If the tokens match, the transfer occurs. The attacker has no way to access the random token value created on the webpage, and if they request the page, the same-origin policy would prevent the attacker from reading the response.

The downside of this method mitigation is it increases the burden on the server-side to check the validity of tokens with each request. It can also create issues if a user has multiple browser windows or other conditions that involve different software making the request. By expanding the scope of the token to be per session instead of per request, some of this difficulty can be avoided.

Cookie-to-header token:

Another method involves issuing a cookie to the visitor’s web browser that contains a random token. JavaScript operating on the client-side will read the value of the token in the cookie and copy it into an HTTP header that will be sent with each request. If a genuine request is sent from the user, the value in the header can be verified by the server. Any other instances will fail, mitigating a successful attack.

By using custom rules through a WAF, users are able to help prevent certain CSRF attacks. Explore Cloudflare’s Web Application Firewall.

*Confused Deputy problem

A confused deputy refers to a computer program that is fooled into misusing its authority. This risk associated with this sort of vulnerability is why capability-based security helps reduce the risks associated with the misuse. When installing software, for example, most computers today require the user to login. This helps prevent code from being executed unintentionally when the user accidentally uses their authority to authorize the installation.