What is Cross Site Request Forgery?

We are happy to welcome you back to our blog series where we are shedding light on the most interesting and useful insights about the top reported vulnerabilities in our Bug Bounty and CVD programs. Within the blog series we have covered XXS vulnerability, IDOR, SQL and today moving on to Cross Site Request Forgery (CSRF) vulnerability.

Are you wondering what is so tricky about this vulnerability and what should you be aware of? Read on to find out the answer to this question, as well as more insights on the different techniques used by the attacker to trick the target, impact of the attack, possible severity levels, and, of course, the way to prevent it!

What is cross site request forgery?

CSRF or cross site request forgery is a vulnerability where a victim is tricked into making a change that they did not intend to. An attacker creates a request that will execute a privileged action, such as changing the current user’s password.The victim is enticed to execute the attacker’s request within his own security context. In this case rather than the attacker changing his own password, the victim’s password is changed. The reason this works is that the security context is sometimes determined by an attribute (e.g. a security token stored in a HTTP cookie) that is automatically added to the victim’s request.

This request will make a change that can only be made by an authorized user and will benefit the attacker. For example, the attacker will try to make someone change their email or password to then take over their account, or create a request that will make a victim transfer money to their account.

There are some conditions that must be met for a CSRF attack to succeed:

There is an action that only authorized users can use that also benefits the attacker.
The request made is validated with the use of cookies.
All required parameters are predictable.
The action should be able to be triggered with a link.

CSRF attacks are similar to reflected XSS in the way they are delivered. For both to be triggered a victim needs to be tricked into clicking a malicious link. With reflected XSS it is possible to receive data from a victim, with a CSRF attack this is not possible.
With CSRF there are different techniques for POST and GET requests.

POST

To create a link for a POST request the attacker can create HTML code that changes his chosen state. With accompanying JavaScript the malicious request can automatically be submitted. This code is then hosted on a website controlled by the attacker and the link is sent to a victim. After clicking the link the browser will include the victims cookies in the request and the website will handle the request normally.

‍GET

When CSRF is possible in a GET request it is not necessary to create HTML code. The payload can be added directly to the URL which can then be sent to a victim.

For example: www.greatbank.com/transfer?to=attacker&amount=1000 would transfer a thousand euros to the attacker’s bank account. To make these attacks less suspicious the URL’s can be disguised as an embedded link. Or by inserting the URL into an image.

For example <img src=”www.greatbank.com/transfer?to=attacker&amount=1000”>. Any medium that tries to load this image will execute the request without the victim’s knowledge as is shown in the picture below.

Impact

The impact of a successful CSRF attack is unauthorized change on behalf of the victim. This change will benefit the attacker, for example:

Submitting or deleting data.
Submitting a transaction.
Purchasing a product.
Changing personal profile details.
Sending a message.

When the user has high privileges a CSRF attack can compromise an entire application.

Severity

The severity of a CSRF attack depends on the impact of the request. A CSRF attack that makes a user logout has informational severity since there is no impact other than it being inconvenient. A CSRF attack with critical or high severity would be an attack that is successful on a user with high privileges. These can grant other users high privileges which could then compromise an entire system.

CSRF attacks can have many severe consequences but because of the different conditions that must be met for a CSRF attack to succeed, the severity can be lower than that of other vulnerabilities with similar impact.

Prevention

CSRF tokens

A CSRF token is a value given to a user by the server-side application. When requests are made by a user the token is validated by the server. CSRF tokens make CSRF attacks impossible because an attacker cannot predict the value of a token. Without the CSRF token or with an invalid token the request is rejected by the server.

To make CSRF tokens effective it should have the following:

The CSRF token should be unique per session.
The CSRF token should be short-lived.
The CSRF token needs to be unpredictable.
The CSRF token should not be stored inside a session cookie.
When transmitted the CSRF token should be treated with the same security as secrets.

In the picture below an example is shown of how the server will deny a request without a CSRF token.

‍

User interaction

Another way of preventing CSRF is with user interaction. Before the user changes anything or tries to make an important request interaction is required. A CSRF attack cannot be made without this extra interaction. For example the user can be made to re-authenticate or use a CAPTCHA.

The downside of user interaction is that it can be annoying for users having to take these extra steps. User interaction is generally only used for important changes like changing a password.

Mitigating

Samesite cookie

The samesite cookie flag can prevent a CSRF attack by preventing the cookie from being inserted into the request sent in a CSRF attack. There are 3 different values for this flag: none, lax and strict.

None will not prevent the cookie from being sent.

Lax will send the cookie if you are navigating to the site through a different domain. But not when a form is submitted.

Strict will only send the cookie if the request originates from the same domain.

Headers

HTTP headers can be used to verify the origin of a request. With the referrer header the origin of the request and the origin of where the request is going to can be determined. If they do not match the request can be denied.

But trusting the headers can be problematic, as headers can be spoofed when combining this attack with XSS.

We hope you enjoyed the blog and that we brought you one step closer to be more aware of possible vulnerabilities and their impact! Stay secure and tuned for the upcoming blog! Meanwhile, check out our previous blogs on the top reported vulnerabilities XXS, IDOR, and SQL.