CSRF (cross-site request forgery) is a type of attack on a site that is carried out using a fraudulent site or a script that causes the user's browser to perform an undesirable action on a trusted site where the user is logged in.
Usually, to do this, the user must click on a fraudulent link (which can be changed using a link shortener).
For example, Jane, who is logged in to the bank's website, checks her email. They may click on a phishing link that includes a request to transfer money to the fraudster's account.
Due to the fact that it is authorized on the bank's website, the bank will process the transfer request.
Which HTTP requests are subject to a CSRF attack?
The GET, HEAD, OPTIONS, and TRACE methods are not subject to CSRF, because they are intended only for retrieving information and do not change the server state.
The POST, PUT, DELETE, and PATCH methods must be protected from CSRF.
Session cookies
Session cookies are a way that the HTTP protocol monitors state. Websites use cookies to identify users and store their data.
Once cookies are saved, the browser sends them to the server with each request to identify the user.
An attacker can use cookies to impersonate the user by forcing the user's browser to execute the request.
If the user is already logged in to the site, cookies will be sent automatically along with the request.
How does cross-site request forgery work?
In order for an attacker to perform a CSRF attack, certain conditions are required:
- The app contains an action that the attacker wants to take – for example, change the password, transfer funds, and so on.
- There are no unpredictable request parameters – an attacker can guess (or know) all the parameters that the application expects to see from this type of request.
- The action can be performed using HTTP requests, and it only relies on cookies to verify that the request is coming from the user.
Web applications that use cookies, browser authentication, or client authorization certificates can be subject to CSRF. Basically, all web applications that automatically add user authentication data to a request are subject to CSRF.
Alternatively, you can start by tricking the victim into uploading or sending information to a web application. This can happen in several ways – for example, through a phishing link.
The exploit can be disguised as a regular link or hidden in an image tag.
Here is an example of an attack via a regular link:
<a href=“harmful link”>Unsubscribe here</a>
Or via the image tag:
<img src=“harmful link” width=“0” height=“0” border=“0”>
Ways to protect against CSRF attacks
Choosing secure frameworks
Use frameworks that have built-in protection against CSRF, such as. NET. It is also important to set up the framework correctly. If your framework doesn't have CSRF protection, you can use Anti-CSRF tokens.
Anti-CSRF tokens
Tokens (or synchronizer token) are a method of server — side protection. The server generates a random unique token for the user's browser and checks it for each request.
The token is located in a hidden field, must be an unpredictable random number and have a short lifetime, without the possibility of reuse.
The token must meet the following conditions::
- be unique within each operation;
- used once;
- have a size that is resistant to selection;
- generated by a cryptographically strong pseudorandom number generator;
- have a limited lifetime.
Using two tokens
The meaning of this method is that two tokens are used: the first one is stored in cookies, and the second one is stored in one of the response parameters.
In this case, the server must check both tokens when receiving one of the unsafe requests.
Using the Same-Site flag in cookies
This flag marks cookies for a specific domain.
This checks the source of the request, and it will not be possible to execute it from a fraudulent site.
This flag is supported by most browsers. It should be used as part of an overall strategy to protect against CSRF attacks.
Require confirmation from the user
For sensitive actions, such as transferring money or changing your password, require an additional action from the user (entering a captcha or confirmation code).
Top comments (0)