application/json - additional security concern?

Tony Hansen tony at att.com
Sun Apr 15 03:42:44 CEST 2007


Graham Klyne wrote:
> Regarding:
> 
>   http://www.ietf.org/rfc/rfc4627.txt
> 
> I recently noticed a blog entry and claim of a potential security vulnerability
> with application/json data, posted here:
> 
>   http://bob.pythonmac.org/archives/2007/04/05/fortify-javascript-hijacking-fud/
> 
> I've not analyzed the details, but there's a clear implication of a potential
> but easily defended route to exploitation in some browsers.
> 
> One of the examples in RFC 4627 (the array example) appears to be of a form that
> the article claims is vulnerable.

Yeah, there's a bunch of press going on right now with taglines similar
to the following:

	New Ajax Attack Poses Threat To Web 2.0 Sites
	A new attack called JavaScript Hacking allows hackers to pretend
	to be a victimized user and request private information.

The tagline is actually not correct, because it's not AJAX that's
vulnerable but asynchronous use of JSON. And the vulnerability is data
leakage by invoking arbitrary JSON providers, and then accessing the
data within.

Because of the "same source rules", XML URLs are not allowed to be
loaded from other web sites. However, Javascript files *are* and
subsequently JSON URLs can be loaded. That is, you can use <script> tags
to load in Javascript files from all over the place to create your final
page. (I believe this is how Google Map mashups are performed.) The
JavaScript Hacking exploit uses <script> tags to load JSON files, and
various Javascript tricks to then capture object creation and access the
data.

The solutions are: 1) don't use JSON as your data transport format, or
2) use {} at the outer scope of your JSON to prevent the Javascript
tricks from working, or 3) prevent the JSON files from being downloaded
from sites you don't control (by using appropriate cookies *and* URL
arguments), or 4) prevent the JSON files from being used directly as
Javascript, but require them to be preprocessed before being eval'd.

Solution (4) can be done by inserting comment characters around the
code. I've read that Google does it by nastily adding a "while(1);" to
the beginning of their JSON code; anyone trying to use this exploit on
Google's JSON files will get an infinite loop instead of data.

	Tony Hansen
	tony at att.com


More information about the Ietf-types mailing list