Cross Site Request Forgery (English)

1337 h@ck34

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

A Metapahor

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!

Technical Example

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 <form></form>tags. However, the HTML/Javascript would be located on a website that an attacker owns and on loading of that website it would send the attacker-controlled HTTP request causing an ill intended effect for the victim. For this example, we’ll use a bank application that contains a function to let the user transfer funds. When a user completes this action, the HTTP request will look like the following

POST /account/transfer HTTP/1.1
Host: vulnerable-bank.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

funds=1000&targetaccount=3301

The POST request uses a cookie to verify the user’s session and takes two body arguments: funds and 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:

<html>
<body>
<form action="https://vulnerable-bank.com/account/transfer method="POST>
<input type="hidden" name="funds" value="1337">
<input type="hidden" name="targetaccount" value="8008>
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>

The code works as follows:

  1. The form tag will specify the POST request to the appropriate endpoint.
  2. The input tags 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 script tag 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

Prerequisites

In order for a CSRF attack to work, you must identify three things:

  1. 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.
  2. Cookie-based session handling. The application only uses cookies to identify the user who makes the requests. There is no other mechanism such as a CSRF token for tracking a user’s sessions or requests. Look below for more info on CSRF tokens.
  3. 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/transfer request has another parameter for 2fatoken then 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
Host: vulnerable-bank.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

funds=1000&targetaccount=3301&csrftoken=CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz

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

100 lines of code, 100 terminal commands, 100 payloads and 1337 hacks only. Twitter: @OneHckMN1