Wednesday, March 14th, 2007

Securing your JSON

Category: Articles, JSON

Bas Wenneker read Joe Walkers piece on the insecurity of JSON and put two and two together with Dean Edwards Array hack to provide an idea on securing your JSON.

javascript

  1. var applyArrayHack = function(){
  2.     //hackzor the Array object using Joe Walker example
  3.     this.Array = function() {
  4.       var obj = this;
  5.       var ind = 0;
  6.       var getNext = function(x) {
  7.         obj[ind++] setter = getNext;
  8.         if (x) alert("Data stolen from array: " + x.toString());
  9.       };
  10.       this[ind++] setter = getNext;
  11.     };
  12. };
  13.  
  14. var applyArrayFix = function(){
  15.     //Create an iframe, I know this is not the best way,
  16.     //doesn't work in Safari blah blah
  17.     var iframe = document.createElement("iframe");
  18.     iframe.style.display = "none";
  19.     document.body.appendChild(iframe);
  20.  
  21.     //Write a script into the iframe and steal its Array object
  22.     //Overwrite the hacked Array with the one from the iframe.
  23.     frames[frames.length - 1].document.write(
  24.         "<script>parent.Array = Array;</script>"
  25.     );
  26. };
  27.  
  28. applyArrayHack(); //apply the hack
  29. var hack1 = [ 40 ]; //=> alerts 40
  30.  
  31. applyArrayFix(); //apply my fix
  32. var hack2 = [ 40 ]; //=> doesn't alert! Yay!

The Downside

The downside of this fix is that you don’t know when to apply the fix. A hacker can use a delayed or interval function to apply the hack, so basically each time you touch an Array object you’ve to apply the fix to be sure it’s safe to send data.

Posted by Dion Almaer at 6:27 am
11 Comments

+++--
3.2 rating from 28 votes

11 Comments »

Comments feed TrackBack URI

why going around the problem,the problem is that some on run malicious code on your site when he doesn`t should have,you need to protect yourself from that not from the effects of that problem.

Comment by uriel katz — March 14, 2007

Two things wrong with this fix:

1) The stealing trick, which this is supposed to protect against, which involved overriding the Array prototype, is meant to be performed on the hacker’s website. The Array protection method suggested above also has to be performed on the hacker’s website in order for the protection to work, and so good luck getting the hacker to insert that code in their own website.

2) To get around point 1, one could insert that code by merging it as part of the JSON. But then it becomes an arms race as the hacker could override the browser functions to prevent you from creating an iframe and hence still preserve their malicious Array prototype.

Comment by Nathar Leichoz — March 14, 2007

hacker can use a delayed or interval function to apply the hack, so basically each time you touch an Array object you’ve to apply the fix to be sure it’s safe to send data

setInterval(function(){applyArrayFix = applyArrayHack}, 1);
… what a post … :/

Comment by Andrea Giammarchi — March 14, 2007

And when one give the applyArrayFix some random name?
… what a comment … :/

I’m not saying this is protected json from being read by hackers, but at least it tries to do something.

Comment by Bas — March 14, 2007

I’m not saying this is protected json from being read by hackers

You’re not showing us anything that increase protection and please, call them cracker, not hacker. bye

Comment by Andrea Giammarchi — March 14, 2007

P.S. Bas, what a post was for Dion Almaer choice, not for your exepriment. You’re obviously free to try to increase security with every kind of function but in this case if You say that someone should use a delayed or interval function to apply the hack I can replay that if “He” can use code he can do everything and change every function, your one too.
Regards

Comment by Andrea Giammarchi — March 14, 2007

Anything that uses delayed execution, a la setInterval, to protect against a security hole trades a security hole for a race condition.

Comment by Andy — March 14, 2007

The main reason I wrote this article is because I wanted to show that a hack like the one Joe Walker showed us isn’t making JSON more insecure than it already is. I am aware of the fact that hackers can break this fix like a snap. And I totally agree with Joe: I believe that JSON is unsafe for anything but public data unless you are using unpredictable URLs. Like you said, this is an experiment…

Comment by Bas — March 14, 2007

I meant crackers :)

Comment by Bas — March 14, 2007

As has already been noted, this fixes nothing if the cracker doesn’t run it on evil.com. And adding the script to JSON replies turns JSON into JavaScript, which breaks stuff. *sigh*

Comment by Luke Arms — March 14, 2007

mmm as the first poster said, I think the key is to being protected against things like CSRF in the first place (with temporary tokens for example)… trying to protect the arrays will not fix the bigger issue…?

Comment by SilverTab — March 14, 2007

Leave a comment

You must be logged in to post a comment.