Wednesday, March 14th, 2007
Securing your 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:
-
-
var applyArrayHack = function(){
-
//hackzor the Array object using Joe Walker example
-
this.Array = function() {
-
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;
-
};
-
};
-
-
var applyArrayFix = function(){
-
//Create an iframe, I know this is not the best way,
-
//doesn't work in Safari blah blah
-
var iframe = document.createElement("iframe");
-
iframe.style.display = "none";
-
document.body.appendChild(iframe);
-
-
//Write a script into the iframe and steal its Array object
-
//Overwrite the hacked Array with the one from the iframe.
-
frames[frames.length - 1].document.write(
-
"<script>parent.Array = Array;</script>"
-
);
-
};
-
-
applyArrayHack(); //apply the hack
-
var hack1 = [ 40 ]; //=> alerts 40
-
-
applyArrayFix(); //apply my fix
-
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.
3.1 rating from 22 votes
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.
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.
setInterval(function(){applyArrayFix = applyArrayHack}, 1);
… what a post … :/
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.
You’re not showing us anything that increase protection and please, call them cracker, not hacker. bye
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
Anything that uses delayed execution, a la setInterval, to protect against a security hole trades a security hole for a race condition.
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…
I meant crackers :)
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*
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…?