|
Oct 14
2009
|
Exploiting a back-office application with CSRFPosted by: Dave on Oct 14, 2009 |
|
In the recent Getting Real with Realex discussions I raised the issue of Cross Site Request Forgery (CSRF) and how the use of a second password for the refund request would prevent it. I received some feedback requesting that I explain CSRF and how it could be used to exploit an back-office application that was not exposed on the Internet.
This blog post will detail a simple example of how a CSRF vulnerability could be used by an external party to perform a refund using a back-office application. Remember that this back-office application is not accessible from the Internet. The back-office application is running on a server on an internal network and is only accessible by employees within that office environment. To start with, we will look at how an internal user would perform a refund using our example back-office application. They would log into the application and find the transaction they want to view. The following mock-up will illustrate how the transaction view might look.
In the above illustration you can see there is a button to refund the transaction. When the user clicks on this button the web browser will submit a HTTP POST to the server to request it to carry out the refund. The HTTP POST would generate a request that looks something like this:
POST http://app/transaction.php HTTP/1.1
...
...
...
transactionID=105
From the above HTTP Request you can see that the transaction ID is passed as a parameter to the server to indicate which transaction the user requests be refunded. When the user clicks on the refund button the refund is executed and the user is then presented with the following screen.
Now we know how the application works when a valid user is using it. In order to do the above refund the user would need to be logged into the application and have permission to carry out refunds. Based on our knowledge of how the system works we can create a URL that will execute the refund request on the server.
http://app/refund-transaction.php?transactionID=105
Obviously this URL will only work when executed by the user who is logged into the application and has permission to carry out refunds. If the user was to open a new tab in their web browser and paste in this URL then the refund would be executed. The goal of an attacker hoping to exploit CSRF is to get the user's web browser to make a request to the above URL. There are various approaches that can be taken to achieve this. We will keep our example simple and look at a common approach.
<img src="http://app/refund-transaction.php?transactionID=105" border="0" width="1" height="1">
The above HTML code, when rendered by a web browser will submit a request to the URL contained in the "src" attribute. If the attacker can get this HTML to be rendered by a legitimate user who is logged into the back-office application, then the request would be executed with the correct permission and the refund carried out. The web browser will attempt to display the result of the request as a 1x1 image. This means the legitimate user will not see any visual indication that the refund has occurred only an small icon displayed by the web browser to indicate that it cannot load the request image.
The next step with this exploit is to find a way to get this HTML rendered by the victims web browser. There are various different options for an attacker to use to achieve this such as:
- Placing the HTML code within an email that is sent to the victim
- Placing the HTML code on an external website and getting the victim to visit this site
- Getting the victim to view the HTML via the user of a social networking site
- Getting the victim to view the HTML on a website that they trust which contains an Cross Site Scripting (XSS) vulnerability
The above example has been simplified to help illustrate the process. Hopefully after reading it you can see the security benefit of requiring users to re-authenticate when they wish to perform certain actions. There are other methods of protecting against CSRF but requiring the user to authenticate themselves again is a simple, effective solution. Use of a secondary password can cause confusion with users and generate more support requests as a result, a point made to me by David Rice in a recent discussion. As with most things in the world of security its all about risk and balancing security needs with usability needs. Depending on your specific business the risk of CSRF and the cost of implementing a solution may well outweigh the usability issues encountered with the above solution. I would go as far as saying that a perfectly secure application would be unusable and a perfectly usable application is insecure.
Note: I have used HTTP GET rather than HTTP POST in the above example to keep things simple so I could illustrate the concept. It is worth noting that configuring your application to only accept HTTP POSTs does not prevent CSRF. CSRF is possible with HTTP POST but it is a little more complicated.
Still not convinced? Take a look at these two real world examples of CSRF -
- Gmail "Change Password" functionality vulnerable to CSRF
- Gmail vulnerable to contact list hijacking
- BT Home Hub router prone to CSRF
Dave
--
If you liked this article then you can:
- Subscribe to our
Blog RSS feed - Become a fan of webpayments.ie on Facebook
- Follow us on Twitter
Related Blog Posts:
written by Security Ninja , October 14, 2009
Nice post Dave, CSRF is one of those vulnerabilities that I find difficult to explain sometimes. It almost seems too simple to be a powerful exploit!
It is worth noting that this clearly shows that the Same Origin Policy is truly broken as a protection mechanism for web users. The "script", "iframe" and "img" src tags have to violate the SOP by design.
The second Gmail vulnerability you linked to is a great example of a Web 2.0 twist on a Web 1.0 vulnerability.
JSON would have prevented the exploit occurring normally because it has protection mechanisms inbuilt that are similar to the SOP - only access resources on your own domain basically. The problem occurred when the researcher figured he could use a JSON callback. The callback allows you to wrap your JSON query in a Javascript function - i.e. execute it from a "script" tag - cross domain access enabled, contact list stolen.
SN
written by Patrick , October 15, 2009
In your text above, you mention this:
"When the user clicks on this button the web browser will submit a HTTP POST to the server to request it to carry out the refund."
Subsequently, you describe CSRF using a GET URL "http://app/refund-transaction.php?transactionID=105". If the application is configured to accept the transactionID as a POST parameter only, then neither copy/pasting the URL nor doing the CSRF trick would trigger the refund.
written by dave lowry , October 15, 2009
Hi Patrick,
Yes you are correct my CSRF example uses HTTP GET rather than HTTP POST but I explained in a note at the end of the post that CSRF is still possible even if you only accept HTTP POSTs. It is a little more complicated than using HTTP GET so I choose to use HTTP GET in order to keep things simple so I could explain the concept.
Thanks,
Dave
written by David Rice , October 16, 2009
Hey David, nice article illustrating the need to secure back office web based applications.
It does however assume the attacker has some knowledge of the system which narrows down the people it could be. So perhaps a disgruntled employee.
This fact alone would also change in my view the possible motivations for such an attack. Which would further reduce the possibility of such an attack occurring.
a) vandalism
b) monetary
Because a monetary incentive could only be gained by defrauding a company of service or goods, it would require real delivery addresses credit card number to be processed first, receive the goods then automatically refund their transaction.
So not exactly a reason to leave securing a back office application. Just to say, the probabilities that someone will be motivated to bother with an attack are quite small.
In particular for applications I develop I'm generally not too worried about CSRF as it is a golden rule of thumb of mine to perform all destructive or modifying actions via HTTP POST, coupling this with an authentication token generated as the HTML is created which must be submitted with the POST or else it is made invalid.
This would be a definite plus for using a *good* open source web framework (like Ruby on Rails) which has CSRF protection similar to what I've described built right in. Although if we're using a framework it's very important then to keep uptodate with security patches as a potential intruder could figure out your application is written in a certain framework and therefore have more information to prepare his attack.
It's all about trade-offs... totally agree with your point about requiring reauthentication for some actions. If not for the CSRF reasons for the fact someone could leave their computer on and leave the room. Opening the door for someone to just come along and perform anything as that logged in user. I like the paradigm of "timing out" a user session after a set ammount of time or period of inactivity.
written by dave lowry , October 20, 2009
Hi David,
I agree the article assumes the attacker has some knowledge of the system but I do not agree that this narrows down the people it could be. An attacker could gain the knowledge needed via social engineering tactics. Admittedly this could take a considerable amount of time and you could question their motivations for carrying out such an attack that requires this amount of investment.
I agree the probabilities that someone will be motivated to bother with such an attack maybe quite low so it really comes down to risk and how you manage it. What is the risk of such an attack occurring? What is the risk to your business such an attack did happen?
Like you said its all about trade offs and it generally comes down to risk versus cost. But as you pointed out there are lots of ways to defend against CSRF such as using a good open source web framework such as Ruby on Rails which provides this protection out of the box. So in this case maybe its not just a case of risk versus costs, education comes into the mix. If the developer is educated then CSRF does not need to be considered.
This actually relates nicely to the secure development principles talk that David Rook gave at the recent OWASP conference.
http://www.owasp.org/index.php/The_Principles_of_Secure_Development
His point was that we shouldn't be focusing on teaching developers about the various threats such as SQL injection, CSRF, XSS etc but instead focus on a set of development principles that will prevent the large majority of threats.
Dave
