Cross Site Request Forgery Explained

Introduction

CSRF stands for Cross Site Request Forgery. It is an attack in which the attacker pretends to be an authenticated user on a website and sends unwanted requests to the website, and the website backend thinks that the authenticated user is making the request. This can be done in many ways. The attacker could steal the cookie of the authenticated user and pretend to be the user on a specific website and perform any malicious requests to the website, like transferring money, deleting an account, etc. Another way to perform CSRF is to maliciously include malicious parameters in a link from a website to the victim website. A website is vulnerable to CSRF if it authenticates the user using GET requests. A malicious website could also have disguised a form which performs CSRF.

Overview

The web works by sending data to and fro. Their are mainly two ways of sending data: GET and POST request. When you use GET request, the data which is sent as a parameter which is visible in the website address. GET requests are used to fetch data from a server. When using POST request, the data is sent to the server, but it is not visible in the website address. POST requests are used to send data to the server. Example: if you are watching a youtube video, the link would be like youtube.com/watch?v=videoID, here the video id is a GET request parameter, and if you copy paste the link and send it to a friend, when she clicks on it, she would also get the same page. Whereas in POST request, when you post a comment, it is not visible in the search bar address, so even if you copy paste the link and send it to a friend, she would not post the same comment by clicking on that link, unlike she got the same page as you in the case of GET request.

To perform CSRF, the attacker has to authenticate the user on the website via his malicious webiste, that can be done by making certain requests to a particular website in the background. Using GET requests, the attacker can perform CSRF by sending the data in parameters to the website to authenticate the user. When using POST request, the attacker sends the data to a website unnoticed by the user. GET requests are a boon to an attacker as the victim just needs to click the link and CSRF would be performed, this is why websites do not authenticate or perform important actions by storing data in the link parameters.

Examples

• For example: You could hide a tweet form on your malicious website, so when the user clicks a button to post a comment, the event is triggered to tweet the data in the hidden form instead of posting the comment. The attacker authenticates you to twitter in the background using web workers and then sends the POST request to the twitter API to tweet the content from your account, and the tweet might be controversial, and that can cause trouble if you have a great following. The attacker can also make you transfer a million dollars from your account to his account using CSRF.
• A malicious website could also have disguised a form, for example: a money transfer form could have been disguised as a credit card linking form, where the amount field is hidden, and when you authenticate your credit card, and click the submit button, the POST request will go to the bank API instead of going to the malicious website API, thus performing the money transfer from your bank account. You would be authenticated to your bank in another tab or in the background.
• When you post a comment on a malicious website, the website might impersonate you on another website in the background or in another tab, and could do anything on that website by a POST request, like deleting your account.

Preventive Measures

'Referrer' Header

Preventive measures against CSRF were introduced in the HTTP protocol. The preventive measure was to include a Referrer header in the HTTP request, so that the API knows from which website is the HTTP request coming from. But that preventive measure did very less impact to CSRF because most of the users have ad blockers or privacy plugins which just do not allow them to send the Referrer header to the API.

One-time key

Another preventive measures against CSRF is a one-time key, which a lot of websites use these days. One-time key is also called the nonce. Web apps use one-time key to authenticate POST requests or any commands that will have a permanent effect on the user. One-time key is near impossible to break, as it is something completely random, and the attacker cannot authenticate to the website without the nonce. The nonce is sent to the user using authentication apps like Google authenticator or via SMS on the user's phone number. Brute force can also not break one-time key because one-time keys are generally valid for a short period of time.

Same-Origin Policy

The Same-Origin Policy forms a great part of the browser's security policy. Same-origin policy states that data on a particular api on a specific domain can only be accessed by requests from the same domain. This forms the barrier against CSRF, as the requests from other websites won't be able to impersonate the victim on another site. The website web servers should only allow their own domain to make HTTP requests for executing certain commands on the website on the web server.

Synchronizer token pattern

Synchronizer token pattern is also referred to as CSRF token. It is a technique in which the server generates unique and random tokens to authenticate its users' requests. It needs to be unique for each POST request. CSRF tokens should be such that they are only accessible to a specific website. Due to CSRF tokens, the attacker is unable to make POST requests from a malicious origin as the attacker would not have the user's CSRF token. This is made possible due to Same-origin policy. Though, it is not mandatory that CSRF token need to be unique for each request, but the CSRF tokens should only be valid for a short period of time, preventing the attacker to brute force. The CSRF tokens must be declared invalid when a user session expires, because if you do not make the CSRF tokens invalid, the attacker could brute force the token, and then use it to exploit the user again in consequent sessions.

CSRF Phishing attack

A common type of CSRF attack would take place like this:

1. The attacker creates a new account on a website.
2. The attacker makes the new account prone to Self-XSS on the website.
3. The attacker leads the victim to a phishing site, which logouts the victim out of the website on which the CSRF is being performed.
4. The victim is logged in to the CSRF-prone website with the attacker-created account. The victim is logged in, as the attacker tricks the victim to click a button on the phishing site which leads to the CSRF-prone website.
5. Self-XSS is executed in the attacker-created account on the victim's computer which cleverly asks the victim to input his password
6. The password is sent to the attacker
7. The attacker authenticates the user to the website using the credentials entered, so that the user thinks that nothing has happened.