Category: security

Update: March 5th 2007:  Important change to the recommendation for Safe JSON detailed below.  It is not as safe as people think, but it can still be made to be safe.

We have been investigating the security implications of having a JSON api in Connections. It turns out that it is very easy to leave pretty big security exposures in an application if it isn’t done right.  The security exposure in this case is rogue sites being able to get at data made available via a JSON api.  The truly frightening part of this is that applications installed on a corporate intranet can actually leak data to internet sites should a user visit a rogue site. BTW, these exposures apply equally to both formally published api’s such as Yahoo’s and also any internal JSON api’s often used for AJAX tricks.

As far as I can make out there are 3 different approaches used with JSON api’s. Before detailing the vulnerabilities I’ll highlight the three approaches using the Yahoo examples (you might want to familiarize yourself with the examples before reading any further). The three approaches are :

Approach 1 – Plain JSON

Simply return JSON i.e.

{
  "Image": {
    "Width":800,
    "Height":600,
    "Title":"View from 15th Floor",
    "Thumbnail":
    {
      "Url":"http:\/\/scd.mm-b1.yimg.com\/image\/481989943",
      "Height": 125,
      "Width": "100"
    },
  "IDs":[ 116, 943, 234, 38793 ]
  }
}

Approach 2 – var assignment

Assign the JSON object to some variable that can then be accessed by the embedding application (not an approach used by Yahoo).

var result = {
  "Image": {
    "Width":800,
    "Height":600,
    "Title":"View from 15th Floor",
    "Thumbnail":
    {
      "Url":"http:\/\/scd.mm-b1.yimg.com\/image\/481989943",
      "Height": 125,
      "Width": "100"
    },
  "IDs":[ 116, 943, 234, 38793 ]
  }
}

Approach 3 – function callback

When calling the JSON Web Service pass as a parameter a callback function.  The resulting JSON response passes the JSON object as a parameter to this callback function.

callbackFunction( {
  "Image": {
    "Width":800,
    "Height":600,
    "Title":"View from 15th Floor",
    "Thumbnail":
    {
      "Url":"http:\/\/scd.mm-b1.yimg.com\/image\/481989943",
      "Height": 125,
      "Width": "100"
    },
  "IDs":[ 116, 943, 234, 38793 ]
  }
})

All approaches can be used via an XMLHttpRequest followed by a javascript eval, but as Yahoo points out Approaches 2 & 3 unlike Approach 1 don’t "run afoul of browser security restrictions that prevent files from being loaded across domains." as…

"Using JSON and callbacks, you can place the Yahoo! Web Service request inside a <script> tag, and operate on the results with a function elsewhere in the JavaScript code on the page. Using this mechanism, the JSON output from the Yahoo! Web Services request is loaded when the enclosing web page is loaded. No proxy or server trickery is required."

Indeed they have successfully navigated the browser security restrictions, which I should point out is probably fine for Yahoo as ALL their services only expose publically available data.  However, if a developer coding up an application that contains private data uses the same approach (i.e. Approach 2 or 3) then they have exposed the application to a pretty simple attack.  BTW, I’m defining private data to be any data that should not be publically accessible to the entire world (this probably covers most data on a corporate intranet but also includes any data that requires authenticatation prior to access). Here’s an example.

A user logs into a wiki on the corporate intranet.  This wiki provides a JSON api with a callback function (Approach 3).  The user then visits a rogue site on the internet.  The page from the rogue site, when rendered in the user’s browser, performs a javascript include to the wiki’s json api passing a callback function. This results in data from the wiki being made available to the rogue site’s javascript function in the page via the callback. Further javascript, on the page, can then form POST the data back to the rogue site and as such the data can be stolen. Not good.

Approach 1, on the other hand, does not contain this vulnerability as it can’t be used via a javascript include.  If attempted it does not make the any data available on the page as it is not valid javascript, indeed it, instead, results in a javascript error and so is safe for JSON api’s that contain private data.

Recommendation

I’m going to tentatively propose the following recommendation and would welcome feedback.

When developing a JSON api that contains data that should not be publically accessible to the world use Approach 1 i.e. return plain JSON.  Update: The JSON returned MUST be of type "Serialized Object" and not of type "Array" (as defined by the JSON spec).  (See the March 5th update below for the rationale behind this change).  If the data can be publically exposed then Approaches 2 & 3 have significant advantages in terms of consumability.

Update: March 5th 2007

Joe has pointed out that care still needs to be taken even when using a plain JSON return (Approach 1). From my testing and as others have pointed out the vulnerability that Joe is referring to only applies when returning JSON of type "array" (section 2.3 of  the JSON standard). However, it appears that if you return JSON of type "serialized object" (section 2.2) then, at the moment, I know of no vulnerability.  It’s worth mentioning that arrays can still be present in the JSON as long as they are not at the top level. The example in Approach 1 above is not vulnerable to attack even though it contains an embedded array.  The following structure is vulnerable though

[["ct","Your Name","foo@gmail.com"], ["ct","Another Name","bar@gmail.com"] ]

as google knows only too well

Anyway, I have updated my recommendation.  It remains tentative.

So my previous post described some of the challenges involved in maintaining security in a site, such as a blogging site, that allows unrestricted / unfiltered user authored content and suggested "HttpOnly" cookies could mitigate some of the risk . "HttpOnly" cookies are, however, not a complete solution. 

The remaining problem is described in one of the comments in the mozilla "HttpOnly" bug posting. Here’s a concrete example. I log into my blog at http://blogs.com/robyates. I then visit the blog http://blogs.com/attacker/. Let’s assume that I am using I.E. and that blogs.com uses "HttpOnly" cookies.  The javascript on the attacker’s blog can’t get access to my "HttpOnly" cookie’s, so it can’t steal my session, but it can open a hidden iframe and then use this iframe to make posts, add spam etc. etc.and given that I have an authenticated session it can do all this under my identity, pretty bad.  It can do this as the attackers blog and my blog are in the same domain i.e. http://blogs.com.

Fortunately, this problem is well understood by the large public blogging organizations such as livejournal. Their approach gives each user their own domain and this domain is separate from the management domain. So, for example, my blog could now be http://robyates.blogs.com, the attackers is http://attacker.blogs.com and my blog is managed at http://manage.blogs.com/robyates.  Now due to cross frame scripting security which also applies to XMLHttpRequests, the javascript on the attackers site is rendered useless. Any javascript running on the attacker.blogs.com domain can’t get access to the data on the robyates.blogs.com or manage.blogs.com domain, so my postings can’t be deleted and spam can’t be added.

The key point here, when designing an application that permits user supplied html, is to segment the application into discrete security regions and assign each region a unique domain. This way any erroneous javascript is constrained to some subset of the complete application.

So in combination with carefully constructed domain partitioning of the application "HttpOnly" cookies show real potential  With any luck we’ll see it show up in firefox real soon, as the bug looks to be heading in the right direction.

Finally, having recently learnt all about this so we can recommend topologies for our new blogging application, it’s got me thinking about how secure any JSON based api is, scary stuff!

I am currently working on a multi-user blogging application for corporate deployment. One of the more interesting challenges is how much flexibility we should allow blog posters with their content.  Do we allow them to post javascript and if we do what do we do about XSS vulnerabilities.

Here’s the problem, a user can make a blog post containing any javascript (a property we want to preserve so that we can populate the blog with fancy charting and other tricks only available through javascript).  This post can use XSS attacks against any user viewing the post.  At first glance this doesn’t seem like much of a problem, the attacker only gets to sniff their own blog, however they also get access to the user’s cookies and in a corporate environment, which may be utilizing single sign on, that opens up a big hole in the form of session hijacking.

So what to do?  Google turned up what seems like a really nice solution in IE and it’s a solution that appears to be gaining momentum. Essentially, it allows a cookie to declare that it is not available to javascript in the browser and so session hijacking becomes practically impossible. It does this by simply adding HttpOnly to the end of the Set-Cookie header e.g.

Set-Cookie: USER=123; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly

done, right ?………… WRONG.  It turns out that there are a few things that still need to fall in the place. The firefox community has been debating exactly how to implement it since 2002.  Then there’s the need to be able to set it from Java uh oh, and we still have to figure out what support we get from the cookies set by Websphere, Netegrity, Web Seal et al.

Anyway, it shows a fair bit of promise and yes I know it doesn’t shut down all the vulnerabilities, but it is a step in the right direction and something we’ll certainly be looking into in more detail.