A cross-site request forgery attack is a confused deputy cyber attack 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 another service.
How does Cross-Site Request Forgery Work?
This attack targets state-changing requests, which refer to requests that change data from one value to another. For example, a targeted request might make a purchase or change the value of 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:
- An attacker creates a forged request that, when run, will transfer $10,000 from a particular bank into the attacker’s account.
- The attacker embeds the forged request into a hyperlink, sends it out in bulk emails, and embeds it into websites.
- A victim clicks on an email or website link placed by the attacker, resulting in the victim requesting the bank to transfer $10,000.
- The bank server receives the request, and because the victim is authorized correctly, it treats the request as legitimate and transfers the funds.
CSRF attacks vary in methodology but typically 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 varying 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 another resource.
HTTP POST is used to change state, increasing the need for protection. To this end, web browsers implement security measures called the same origin policy (SOP) and cross-origin resource sharing (CORS) which contain the cross-origin security policy. SOP allows only requests from the same origin, and CORS allows only certain requests 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 can check to see if the two tokens match. If the tokens match, the transfer occurs. The attacker cannot access the random token value created in the webpage, and if they request the page, the same origin policy would prevent the attacker from reading the response.
The downside of this mitigation method is that it increases the server’s burden 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. Expanding the token’s scope to be per session instead of per request can prevent some of this difficulty.
Cookie-to-header token:
Another method involves issuing a cookie to the visitor’s web browser that contains a random token. The client-side JavaScript will read the token’s value in the cookie and copy it into an HTTP header sent with each request. If a genuine request is sent from the user, the server can verify the value in the header. Any other instances will fail, mitigating a successful attack.
By using custom rules through a WAF, users can help prevent specific CSRF attacks.
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 misuse. When installing software, for example, most computers today require the user to log in. This helps prevent code from being executed unintentionally when the user accidentally uses their authority to authorize an installation.
