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.
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.
Once cookies are saved, the browser sends them to the server with each request to identify the user.
If the user is already logged in to the site, cookies will be sent automatically along with the request.
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.
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”>
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.
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.
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.
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).