Definition: Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.
Research Done by : Ovais Khanday
Let us break this huge statement into much simpler statements. Suppose Client A is a user who has logged into the website by passing login-credentials, a token is generated and stored into cookies for him. On all subsequent requests to the same origin the token is sent also, in order to authenticate the user in backend-servers. This is looking fine right, but wait there is a problem. Did you find it? (Nice, I know you are awesome).
Take an example of a banking system. Client A can make a request to transfer some amount of money from his account to ‘OVAIS’. He can do this process in majorly two ways, either via GET method or POST method.
GET Method
When Client A makes the transfer request after he has been authenticated, the URL would look similar to the one below, and the token is also sent in the request header for authentication.
Problem:
A hacker can trick you here. Suppose you got an email and there is an <a> tag which links to:
If you press the link the request will be made to the servers of bank.com, because you are already authenticated (remember that token is there in the cookie) the request will be processed successfully. Because the server does not know the origin of the request. The only thing a server knows is the request. Your account will be debited by the amount the hacker had set, without your knowledge.
You know what is more severe, what if the hacker implanted this link on some website you regularly visit (social engineering). He can also increase the severity by adding an image that will have src attribute linked to the same malicious link, now the user is hacked without his pressing a button. The browser will try to load the image by executing src url. Because the src url is the banking request to transfer a particular amount to the hackers account, it will get executed and the token is already present in the cookie to authenticate the user.
POST Method
Post method doesn’t send data in the url. It sends the data into the request body. The typical bank transfer request using POST method would look like:
In case the system is using the POST method to do transactions, the hacker can not use <a> or <img/> tags because they both operate on GET methods. Because in <img/> src browser GETS the image from the url and in <a> tag browser GETS another possible webpage.
What in HTML can we use to send POST requests?
A form can be used here. The hacker implants a hidden form into another website where the user often visits(social engineering). The form could look like this:
This form will make a POST request to bank.com with two attributes: to and amt. The only thing, which stops the request from being made is triggering the submit event of the form. Even this can be done programmatically by:
What this line does is, it will execute the form right after the document has been loaded into the viewport of a browser. The resultant request would be like:
In both the cases either GET or POST the hacker is able to forge a request on behalf of the user who is authenticated. The solution to this problem is enabling the server to distinguish between the request sent from the actual UI of the legit site and the requests sent from the UI of the malicious site. Let’s move forward to the solution of this problem.
Solution
To defeat a CSRF attack, applications need a way to determine if the HTTP request is legitimately generated via the application’s user interface. The best way to achieve this is through a CSRF token. A CSRF token is a secure random token (e.g., synchronizer token or challenge token) that is used to prevent CSRF attacks. The token needs to be unique per user session and should be of large random value to make it difficult to guess.
A CSRF secure application assigns a unique CSRF token for every user session. These tokens are inserted within hidden parameters of HTML forms related to critical server-side operations. They are then sent to client browsers.
It is the application team’s responsibility to identify which server-side operations are sensitive in nature. The CSRF tokens must be a part of the HTML form—not stored in session cookies. The easiest way to add a non-predictable parameter is to use a secure hash function (e.g., SHA-2) to hash the user’s session ID. To ensure randomness, the tokens must be generated by a cryptographically secure random number generator.
Whenever a user invokes these critical operations, a request generated by the browser must include the associated CSRF token. This will be used by the application server to verify the legitimacy of the end-user request. The application server rejects the request if the CSRF token fails to match the test.
Learn more about the topic: