Monday, October 18, 2010

Cross-Site Request Forgery: Are your web applications vulnerable?

Cross Site Request Forgery (also known as XSRF or CSRF) works by exploiting the trust that a site has for the user. CSRF according to OWASP, is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.



How does the attack work?

There are lots of ways in which an end-user can be tricked into submitting information to or loading from a web application. In order to execute an attack, we need to first understand how to generate a malicious request for our victim to execute.

Let us consider the following example: Sawyerr wishes to transfer #1,000 to Segun using http://bank.com. The request generated by Sawyerr will look similar to the following:

POST http://bank.com/transfer.do HTTP/1.1
acct=Segun&amount=1000


However, Titi discovers that this web application in question will execute the same transfer using the URL parameters below:

GET http://bank.com/transfer.do?acct=Segun&amount=1000 HTTP/1.1

Titi now decides to exploit this web application vulnerability using Sawyerr as her victim. Titi first constructs this URL which will transfer #100,000 from Sawyerr's account right to her account.

http://bank.com/transfer.do?acct=Titi&amount=100000

Now that she has generated her malicious request, Titi needs to trick Sawyerr into submitting it. The easiest way to do this is to send Sawyerr an HTML mail containing the following:

<a href="http://bank.com/transfer.do?acct=Titi&amount=100000">View my Pictures!</a>



We are doing this in assumption that Sawyerr is authenticated with the web application when he clicks the link, the transfer of #100,000 to Titi's account will occur.

But lets say Titi realizes that Sawyerr will notice that a transfer will occur if he clicks the link, Titi can decide to hide the attack in a zero-byte image as below:

<img src="http://bank.com/transfer.do?acct=Titi&amount=100000" width="1" height="1" border="0">



If the code above were included in the email, Sawyerr would only see a little box indicating that the browser could not render the image. However, the browser will still submit the request to bank.com without any vindication(visual) that the transfer has taken place.


How to Prevent this type of attack

Use the cheat sheet provided by OWASP here to prevent this type of attack.

No comments:

Post a Comment