Information inspired from Real-World Bug Hunting. A fantastic book to get into web hacking/bug hunting
Understanding the Idea of Cross Site Request Forgery
Cross Site Request Forgery (CSRF) is the next vulnerability that I have spent the last week and a half learning more about. For me the best way to understand CSRF is to compare it to a child convincing their parent to sign a document for something that the parent is not expecting. For example, if a child wants to get a tattoo but needs a parent signature in order to get it, he might cover the original document with another document (maybe a fake field trip form) except for the bottom page where the signature line is located. Then on an evening where his mother or father is tired from a long day of work, he would ask them to sign the paper. Because they are distracted, they are susceptible to this mischievous plan and will sign without a second thought. Now the child will get a tattoo and bring dishonor to the family!
In terms of a CSRF attack, the attacker will make the victim carry out an action that is not wanted by the victim. This could be changing the account email, wiring money to the wrong account or deleting an account altogether. In this kind of attack, the hacker will craft an HTTP request for a website via
POST /account/transfer HTTP/1.1
POST request uses a cookie to verify the user’s session and takes two body arguments:
targetaccount. However, an evil individual would see this and attempt to change
targetaccount to their own account. To do this they would create a web page that makes a HTTP request to
/account/transfer. Below is the code that would be used:
<form action="https://vulnerable-bank.com/account/transfer method="POST>
<input type="hidden" name="funds" value="1337">
<input type="hidden" name="targetaccount" value="8008>
The code works as follows:
formtag will specify the
POSTrequest to the appropriate endpoint.
inputtags specify the values that will be sent in the request which are the funds and target account number. We mark it as hidden so the victim does not see these fields on screen. The
scripttag is calling the first (and only) element in the array of forms on the page and submits it once the page is loaded
Now an attacker would host this code on his website, have the victim click on the link to that website (through some form of social engineering) and then the
POST request would be submitted. It is extremely important that the victim is currently logged in or the attack will not work because the
POST request that we see uses a cookie value to validate the request.
Understanding When to use CSRF
In order for a CSRF attack to work, you must identify three things:
- An action already performed by the application. This is an action that the victim can already perform within the application. A CSRF attack cannot implement new actions. If an application only has a method to transfer funds but not one to delete an account then you will be unable to create a request to delete an account because the server will receive a request that it is not programmed to understand.
- No unpredictable request parameters. An attacker will not be able to create requests if they contain parameters whose values cannot be determined or guessed. In this case, if the bank application
/account/transferrequest has another parameter for
2fatokenthen a CSRF attack will not work unless you are able to hijack the device that receives the 2fa token or intercept communication between the server and device.
Preventing CSRF with CSRF Tokens
A common way applications will prevent a CSRF attack is to implement CSRF tokens, which are unique, secret and unpredictable values generated by the server-side application and transmitted to the client in such a way that it is included in each subsequent HTTP request made by the client. When the requests are made, the server-side code will validate that the request includes the expected token and if not it will reject the request. Going back to the bank application example, if the request now includes a csrf token such as:
POST /account/transfer HTTP/1.1
then we will be unable to craft a malicious
POST request since we cannot guess the csrf token.
Thanks for reading! This was a little introduction to CSRF. There will be another blog post with more examples of CSRF-based attacks and how, in some cases, we are able to circumvent csrf tokens in order to launch successful CSRF attacks.
Give me a follow on le twitter @OneHckMN1