Thursday, April 5th, 2007

Protecting a JavaScript Service

Category: Articles, Security

<p>There is increasing buzz over security with JavaScript, and people are stepping up to the plate.

In How to Protect a JSON or Javascript Service, Joe Walker looks at a few solutions such as:

  1. Use a Secret in the Request
  2. Force pre-eval() Processing
  3. Force POST requests

Joe implements some of these in DWR, including:

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.

Andrea Giammarchi wonders if 130 bytes are enough to solve JavaScript JSON Hijacking problems? in which he discusses tactics for detecting the hijacking of your objects and comes up with solutions such as this:

javascript
< view plain text >
  1. if((function(c,m,t){t=c[m];delete c[m];if(/^\[XMLHttpRequest\]$/.test(c)){c[m]=t;return 1}})(XMLHttpRequest,"toString"))
  2.  alert("Valid XMLHttpRequest");
  3. else
  4.  alert("XMLHttpRequest is corrupted");

Finally, the GWT team has published an article on Security for GWT Applications that delves into how GWT handles JavaScript vulnerabilities such as leaking data, cross-site scripting, forging requests, JSON and XSRF.

A lot of good stuff.

Related Content:

Posted by Dion Almaer at 8:37 am
5 Comments

+++--
3.5 rating from 31 votes

5 Comments »

Comments feed TrackBack URI

KISS:
$headers = getallheaders();
if(isset($headers['X-Requested-With']) &&
$headers['X-Requested-With'] == 'XmlHttpRequest') {
//...
}

Comment by Nathar Leichoz — April 6, 2007

Nathar, are You sure that a redefined XMLHttpRequest object cannot use setRequestHeader with that property?

Comment by Andrea Giammarchi — April 7, 2007

Andrea, that doesn’t matter. Any attempt to use XMLHttpRequest (or any redefined variation thereof) is restricted by the same-origin policy which means it cannot access data from another domain. i.e., a site at http://www.angelfire.com/~hacker/ cannot access data from http://www.googlemail.com. If it uses a script tag, it cannot set any HTTP headers and so googlemail.com can block it. If it uses XMLHttpRequest, it can call setRequestHeader, but the request would be automatically denied by the browser because it is going to a different domain. Thus, Google can ensure that their JSON data is only accessible to sites hosted on http://www.googlemail.com.

Comment by Nathar Leichoz — April 8, 2007

What about just passing:
(function(){return {..json..};))

That’s simple, the json cannot be accessed without calling the lambda. Seems like the easy answer…

Comment by Peter Goodman — April 9, 2007

One gotcha to keep in mind is that if your server supports the Range header, someone could just use a byte range to fetch the inside of your JSON, rendering your comments and error throwing useless.

Comment by Jed Schmidt — April 20, 2007

Leave a comment

You must be logged in to post a comment.