JSON, JavaScript, and CSRF security holes

2007-04-05 07:57:00

Fortify Security's recent paper on JavaScript Hijacking (PDF) has stirred up a lot of interest online around the subject of JavaScript/JSON security. Some of the articles are a bit alarmist, but it is a vulnerability worth understanding a bit better.

It's based on techniques similar to Jeremiah Grossman's original GMail contact-list hack. (The Subverting Ajax paper by Stefano Di Paola and Giorgio Fedon also uses prototype hijacking, but has some seemingly exotic prerequisites like "a forward proxy and browser vulnerable to HTTP Response Splitting/Smuggling." See Grossman's deconstruction of the paper here.)

The vulnerability described in this new paper (and indeed many of the security issues with Ajax) comes from a confluence of three things:

  1. JSON: It's not just a data format, it can also be executable code.
  2. Remote scripting: Allows you to get around the browser's same-origin security policy, resulting in some other site's JavaScript-code chocolate in your page's execution-context peanut butter. (Sure, it's a hokey metaphor, but you get the idea.)
  3. JavaScript: Everything's mutable, so if you can get someone else's code to run in your page, you have all kinds of opportunities to coax stuff out of it.

There's no point in going into a lot of detail here -- Joe Walker (of the DWR Ajax library) has an excellent blog post on this with some good background linkage, and explanation of some different things you can do to protect your JSON service. But the bottom line is this -- don't serve out executable JavaScript code (JSON or otherwise) with cookies-only auth over GET.

(And for the people who are still hyperventillating over the prospect of being hakz0r3d in horrible ways by their Ajaxy Web UIs, I would also suggest giving Grossman's "Myth-Busting AJAX (In)security" article a read.)

Actually I think the thing that sticks out most to me on reading the JavaScript Hijacking paper is the assumption that it is incumbent on the JavaScript toolkits to protect their users (the developers, that is) from this particular problem:

We determined that among them only DWR 2.0 implements mechanisms for preventing JavaScript Hijacking. The rest of the frameworks do not explicitly provide any protection and do not mention any security concerns in their documentation.

I understand that a lot of people use these libraries precisely because they don't have a lot of expertise in JavaScript or Ajax-style development, but I'm still kind of dubious. I can sure see expecting a mention of these kinds of issues in the docs, but the pure client-side fixes are fairly heavy-handed and intrusive.

As a side note, if you're interesting in playing around with this vulnerability, the authors of the paper used the deprecated setter syntax for the code that does the actual dirty work of filching the private data in the example. A better way to do it is with the __defineSetter__ method.


This is the blog for Matthew Eernisse. I currently work at Yammer as a developer, working mostly with JavaScript. All opinions expressed here are my own, not my employer's.


Previous posts

All previous posts ยป

This blog is a GeddyJS application.