Bryan Sullivan's Web Blog

REST and XSRF, Part One

2008-08-15T18:46:00Z

Hi everyone. In case you missed my talk at Black Hat, “REST for the Wicked”, I wanted to give you the Cliffs Notes version here. This will be a two-part post; the first will deal with attack techniques and the second will describe appropriate design and implementation mitigations for the attacks.

The SOAP vs. REST debate has been raging (or at least simmering) for years now. While I don’t want to offer this blog as another battleground in this war, I do want to talk about some of the security issues affecting REST. Specifically, I want to talk about REST and its susceptibility to Cross-Site Request Forgery (XSRF) attacks.

Let’s look at a sample RESTful web service that provides information on movies and actors and TV shows – let’s call it BryMDB for Bryan’s Movie Database. If a user wanted to retrieve all of the available data for the movie Wanted, she would just make an HTTP GET request like this:

GET /movies/Wanted HTTP/1.1

If she noticed that no one had created an entry for the new James Bond movie and she wanted to add one, she would make a POST request with the movie data in the message body:

POST /movies/Quantum_Of_Solace HTTP/1.1

Similarly, the HTTP method POST is used to update existing data and DELETE is used to delete data. Essentially we have a mapping of data CRUD (Create/Read/Update/Delete) to HTTP methods POST, GET, PUT and DELETE. The problem with this is that unless preventative measures are taken, the service will be extremely vulnerable to XSRF attacks. For example, Evil Eve might write a page with the following HTML and JavaScript code:

<body onload=javascript:document.evil.submit()>
  <form name="evil" method="POST" action="http://www.brymdb.com/movies/Iron_Man" enctype="text/plain">
    <input name="{review:'This movie is horrible! I want my money back!', rating:1}//" value=""/>
  </form>
</body>

Now any visitor to this page will automatically post a negative review of Iron Man, whether they liked the movie or not (or even whether they’ve seen the movie or not)! And Eve doesn’t have to host this page on the brymdb.com domain. She can host this page anywhere and the attack will still be successful.

In terms of REST, the “C” in CRUD as accessed through the POST method is actually the easiest to attack. However, R, U and D are all very much vulnerable as well. We’ll save “R” for last and focus on attacking update and delete functionality now.

It’s more difficult for an attacker to forge PUT and DELETE requests since you can’t specify these methods as the “method” attribute of a <form> element – <form> only allows GET or POST. However, you can specify PUT or DELETE as the HTTP method used for XMLHttpRequest, like this:

var xhr = new XMLHttpRequest(); 
xhr.open("PUT", "http://www.brymdb.com/movies/Kung_Fu_Panda", true); 
xhr.send("{review:'This movie rocks!', rating:10}");

The problem with this (if you’re an attacker) is that you can’t normally make cross-domain requests with XMLHttpRequest. There are two takeaways from this. The first is that this should really highlight the importance of preventing XSS in your applications. Once an attacker can add script of her choice to your pages, she can use XMLHttpRequest to send PUT and DELETE attacks against any REST services on the domain. (Actually at this point, attacks against your REST services are probably the least of your concerns.) The second takeaway is that this also shows the danger of the W3C cross-domain XHR proposal that I’ve previously written about here.

At this point, we’ve addressed means by which an attacker can attack POST, PUT, and DELETE methods, but we haven’t looked any ways to attack the most common HTTP method: GET. At first glance, attacking GET would seem trivial. There are literally dozens of ways to make browsers issue cross-domain GET requests. Here is a sampling of just a few of them:

<img src="http://www.brymdb.com/Movies/WallE"/> 

<iframe src="http://www.brymdb.com/Movies/WallE"> 

<object data="http://www.brymdb.com/Movies/WallE"> 


The problem with this (again from the attacker’s perspective) is that in a true RESTful architecture, GET is only used to read or retrieve data. It does no good to issue forged GET requests if the attacker can’t read the (presumably valuable and confidential) data being returned from the server. You can’t use <img src> or any of the techniques listed above to read data. You can use XHR to issue GET requests and read the responses, but again, you can’t normally make cross-domain XHR requests.
One possibility is to use a Rich Internet Application (RIA) to forge requests across domains. Both Flash and Silverlight allow you to issue cross-domain GET requests and read the responses, assuming that the target domain has an appropriate cross-domain access policy file in place. Silverlight code to perform a request forgery against a REST service would look like this:
void attack() { 
  WebClient webClient = new WebClient(); 
  webClient.DownloadStringCompleted += new DownloadStringCompletedEventHandler(callback); 
  webClient.DownloadStringAsync(new Uri("http://www.brymdb.com/Movies/WallE")); 
} 

void callback(object sender, DownloadStringCompletedEventArgs e) { 
  string stolenData = e.Result; 
  // now send it home… 
} 


For REST services that use JSONP as their response data format, you can also use script to redefine or “hijack” the JSONP callback function. Given this JSONP response body:
myCallbackFunction("{review:'I loved it! It was much better than Cats.', rating:9}");
An exploit page would look like this:
<script type="text/javascript"> 
  function myCallbackFunction(data) { 
    var stolenReview = data.review; 
    var stolenRating = data.rating; 
    // send the stolen data home… 
  } 
</script> 
<script src="http://www.brymdb.com/Movies/WallE"/> 


Notice the second <script> tag at the bottom of the page that calls the target REST service. We can use this trick since the service is returning JSONP, and JSONP is valid JavaScript. The cross-domain limitation we had with XHR and the RIAs does not apply here; you can use <script src> to call any domain on the internet, regardless of whether that domain has defined a cross-domain access policy.
A variation of the JSONP hijacking attack shown above is to redefine the built-in JavaScript object constructor instead of the JSONP callback function. This attack will work on straight JSON as well as JSONP. However, most browsers (including IE) do not allow you to redefine the object constructor, which greatly reduces the potential pool of victims that could be affected by this attack.
Well, we’ve talked a lot about possible XSRF attack vectors against REST services. Next time, we’ll shatter the myth that XSRF is indefensible and present some mitigations for these attacks.

Show some respect to XSS

2008-06-11T19:48:00Z

StickyMinds.com has just posted an article of mine on the dangers of XSS. (Although they still have my old bio from when I worked at HP, I'll have to get that changed!)

SQL injection in classic ASP

2008-05-30T19:05:00Z

In light of the recent wake of SQL injection attacks on ASP sites, I'd like to highlight some relevant resources for learning about and responding to the threat.

Bala Neerumalla has written a detailed document for preventing SQL injection in ASP (that is, classic ASP, not ASP.NET).

The Security Vulnerability Research & Defense blog has posted an analysis of the attack, along with guidance recommendations for IT/database admins, web developers, and end users.

Finally, Michael Howard recently wrote a post on the SDL blog on SQL injection defenses required by the SDL.

Web Application Firewalls in Practice - or - Yes, Jeremiah, Secure Software Does Matter

2008-05-19T19:01:00Z

There's been a lot of renewed interest in web application firewalls lately. In the past, I haven't been a huge fan of WAFs - they always seemed to me to be just a band-aid stuck on the sucking chest wound of insecure code. But I bumped into Jeremiah Grossman at BlueHat, and he raised some good points in defense of WAFs, the most compelling of which was the use of WAFs as emergency first-response tools. Consider the recent mass SQL injection attacks. Fixing these vulnerabilities is going to cost a lot of time and a lot of money. What if, instead of taking the vulnerable sites down while they're getting fixed (or worse, just leaving the sites up and vulnerable while they're getting fixed), the admins put WAFs in front of the sites to keep them up and running while the security holes get patched?

Now, I like this idea a lot. In theory. But in practice, what I'm afraid will happen is that the WAF will get put up as an emergency response, and then the actual code fixes will never get written because they'll take a long time and they'll cost a lot of money and why should we bother because we're already protected from the threat anyway?

Maybe I'm being overly cynical about this. Right here, right now, I'm going to publicly change my stance on WAFs. WAFs can be an excellent defense-in-depth measure and a good emergency first-response tool, but they will never be a replacement for secure code or a secure software development lifecycle. Instead of a band-aid, think of a WAF as an all-star shortstop (or guard, or linebacker, depending on your sport of choice). He'll save you some runs, but you can't put him out on the field all by himself.

Cross-domain XHR will destroy the internet

2008-04-04T23:23:00Z

Ok, maybe “destroy the internet” is a little harsh. But let’s take a look the impact that implementation of the current W3C working draft for cross domain access would have on browser security. Some people might argue that there’s no more risk from cross-domain XHR than there is from cross-domain Flash or Silverlight, but they would be wrong, for two reasons.

First is a simple matter of increased attack surface. Flash and Silverlight support only the HTTP methods GET and POST. But attacks can be made with methods other than these, and XHR supports any arbitrary method. Attackers could send TRACE requests to probe for cross-site tracing vulnerabilities that defeat HttpOnly cookie protections. Or they could send PUT or DELETE requests to attack WebDAV sites or RESTful web services.

In the second place, cross-domain XHR would increase the potential damage of a successful XSS. Arguably the worst, most damaging types of XSS attacks are the self-propagating XSS web worms. At Microsoft, any “wormable” vulnerability automatically gets our highest security bulletin rating. But for the most part, XSS web worms are confined to a single domain because of the constraints of the same origin policy. Now single-domain worms are bad enough – just ask MySpace – but cross-domain XHR would allow worms to spread across multiple domains, potentially infecting any site with both a stored XSS vulnerability and a permissive cross-domain policy.

Billy Hoffman and John Terrill presented some excellent material on cross-domain web worms at Black Hat last year, but their approach relied on using blind GETs and POSTs to propagate across domains. An attack based on cross-domain XHR would not be limited in this way; the worm could read responses from the targets and vary its attacks accordingly. It could even include logic to defeat multiple-step submission processes like CAPTCHA checks.

I know the cross-domain genie is out of the bottle now with pretty much every browser and RIA framework providing its own cross-domain request mechanism, but let’s try to kill this proposal and nip a future security nightmare in the bud.

As an alternative to the W3C XHR proposal, I like IE8’s XDomainRequest (XDR). XDR only allows GET and POST requests, which is a good reduction in attack surface, but even better is the fact that XDR won’t ever send cookies. This is going to make exploitation of XSRF vulnerabilities via XDR impossible in most cases. Theoretically the web worm issue is still possible, but an attacker would have to find sites that:

a. Have persistent XSS vulnerabilities,

b. Have permissive cross-domain policies, and

c. Don’t use any kind of authentication or session cookies.

Even assuming that any sites like this actually exist, the no-cookies restriction definitely limits the effectiveness of XDR as an attack vector compared to the W3C proposed standard.

BlueHat shows some love to web app security

2008-03-24T23:43:00Z

If you haven't heard yet, BlueHat v7 is dedicating the entire block of morning sessions to web app security issues. I'll be there, talking about my first 30 days as the new web app sec guy on the SDL team. Hope to see you there!