from __future__ import *

Kailash and Friends Kailash Kher Kaipa

Recently, Fortify Software has claimed that there is a pervasive and critical vulnerability in Web 2.0 with their JavaScript Hijacking paper. The way they wrote the paper is extremely misleading and was likely constructed this way on purpose to garner press and business for their company.

The first egregious dishonesty in their paper is that it analyzes client-side Ajax frameworks. This is not where the vulnerability is, nor where it's fixed. The service's intended client-side JavaScript code is not even executed during ANY PART of the demonstrated exploit! However, client-side Ajax frameworks are a hot topic, so what the hell, let's blame them.

The second is that they do not enumerate all of the preconditions required for the exploit. The client must support JavaScript setters. The only browser that I've found that supports these are Firefox. Internet Explorer 6, Safari, and Opera are NOT VULNERABLE to the specific exploit described in the paper. The paper claims that "all of the examples in the paper could be adapted to work under Internet Explorer too". Oh yeah? Prove it.

And MOST importantly the exploit is only applicable to JSON that also happens to be valid JavaScript code. The only type of JSON that is valid JavaScript code without parentheses is a JavaScript array (or bare primitives, but those are not interesting or exploitable). That's right, the simplest fix is to always make sure you send an object on the outside, not an array.

Exploitable:

[{"object": "inside an array"}]

NOT Exploitable:

{"object": "not inside an array"}

Also NOT Exploitable:

{"result": [{"object": "inside an array"}]}

The simplest solution is to just change the JSON RFC to include a strong recommendation that only objects should be allowed as an envelope. Server-side frameworks should give error or provide warning when an array is serialized without a containing object. I notified them of this before the paper was published, but they ignored my suggestion and instead went for the more complicated suggestion of trying to add backwards-incompatible sludge to JSON.

I've crafted a little example that shows which browser you're using and the attacks that were successful. The Fortify exploit is "Array/Object JSON vulnerable". The two other tests are for JSON documents not contained by an array. The Fortify exploit is the only one that succeeds, and it only succeeds in Firefox.

Ryan Wilcox has recently written an excellent article for Linux Journal: MochiKit by Example. Check it out!

http://www.linuxjournal.com/article/9552

While I didn't personally attend Freedel 06, I recently came across the slides for Anant Narayanan's Web Application Development talk. Specifically it covers JavaScript web application development with MochiKit and Dojo, and it's split into four sets of slides. I've just had a chance to give them a look and they're quite good.

The slides are all done with S5, which is what I used for the MochiKit Intro talk I gave a few months ago.

Part 1 - JavaScript:

A general overview of JavaScript and AJAX

Part 2 - MochiKit:

An overview of what MochiKit is and why you'd want to use it. Lots of pointers to cool features such as DOM and Signal.

Part 3 - Dojo:

Covers a bunch of the great functionality that Dojo has that isn't available anywhere else such as widgets, layout, animation, and offline storage.

Part 4 - Case Studies:

A few very short case studies of some JavaScript web applications.

The slides from my MochiKit Intro talk at The Ajax Experience 2006 are up:

http://svn.mochikit.com/presentations/2006/ajax_experience/slides.html

They were built with a slightly modified s5 (so that I could toggle an interactive mode with ctrl-i to demonstrate MochiKit inline without advancing the slides), using the docutils rst2s5 tool.

The reStructuredText source, build scripts, etc. are all in the repository here:

http://svn.mochikit.com/presentations/2006/ajax_experience/

MochiKit 1.3.1 is now available [download].

This is a bug fix release of MochiKit 1.3, which includes some minor documentation improvements and the following important fixes:

• Fix sendXMLHttpRequest sendContent regression
• Internet Explorer fix in MochiKit.Logging (printfire exception)
• Internet Explorer XMLHttpRequest object leak fixed in MochiKit.Async

MochiKit 1.3 "warp zone" is now available [download, release announcement].

The most significant feature for this release is MochiKit.Signal, an excellent system for handling events cross-browser.

We've also spiffed up some of the examples and added a few new ones, and as per usual we've combed over our extensive documentation and made a bunch of improvements.

For all of you ajaxians out there, The Ajax Experience is coming up next month! From the roster it looks like it's going to be quite the conference. There are representatives speaking for quite a few of the ajax-related frameworks and libraries (including my Intro to MochiKit), as well as the people responsible for JavaScript, JSON, and just about everything else a "web 2.0" developer should be intimately familiar with.

The Ajax Experience runs from May 10th-12th at the Westin St. Francis right here in rainy San Francisco.

For those of you not able to attend, I will definitely be making all of my presentation materials available after the talk, but I would highly recommend showing up if you can. In my experience, the talks are the least interesting part of any conference.

MochiKit 1.2 "the ocho" is now available [download, release announcement].

This release is the calm before the storm, it contains mostly bug fixes and minor functionality improvements -- but big things are coming soon. We have a signal/slot dispatch mechanism, a script.aculo.us port, a new testing system, non-browser compatibility (SpiderMonkey, KJS, SpiderMonkey, Rhino) and a normalized event object all in the works which will be hitting the trunk soon. For more information about the new features check out the mailing list and the trac instance.

The browser security model dictates that XMLHttpRequest, frames, etc. must have the same domain in order to communicate. That's not a terrible idea, for security reasons, but it sure does make distributed (service oriented, mash-up, whatever it's called this week) web development suck.

There are traditionally three solutions to solving this problem.

Local proxy:

Needs infrastructure (can't run a serverless client) and you get double-taxed on bandwidth and latency (remote - proxy - client).

Flash:

Remote host needs to deploy a crossdomain.xml file, Flash is relatively proprietary and opaque to use, requires learning a one-off moving target programming langage.

Script tag:

Difficult to know when the content is available, no standard methodology, can be considered a "security risk".

I'm proposing a new technology agnostic standard methodology for the script tag method for cross-domain data fetching: JSON with Padding, or simply JSONP.

The way JSONP works is simple, but requires a little bit of server-side cooperation. Basically, the idea is that you let the client decide on a small chunk of arbitrary text to prepend to the JSON document, and you wrap it in parentheses to create a valid JavaScript document (and possibly a valid function call).

The client decides on the arbitrary prepended text by using a query argument named jsonp with the text to prepend. Simple! With an empty jsonp argument, the result document is simply JSON wrapped in parentheses.

Let's take the del.icio.us JSON API as an example. This API has a "script tag" variant that looks like this:

http://del.icio.us/feeds/json/bob/mochikit+interpreter:

if(typeof(Delicious) == 'undefined') Delicious = {};
Delicious.posts = [{
    "u": "http://mochikit.com/examples/interpreter/index.html",
    "d": "Interpreter - JavaScript Interactive Interpreter",
    "t": [
        "mochikit","webdev","tool","tools",
        "javascript","interactive","interpreter","repl"
    ]
}]

In terms of JSONP, a document semantically identical to this would be available at the following URL:

http://del.icio.us/feeds/json/bob/mochikit+interpreter?jsonp=if(typeof(Delicious)%3D%3D%27undefined%27)Delicious%3D%7B%7D%3BDelicious.posts%3D

That's not very interesting on its own, but let's say I wanted to be notified when the document is available. I could come up with a little system for tracking them:

var delicious_callbacks = {};
function getDelicious(callback, url) {
    var uid = (new Date()).getTime();
    delicious_callbacks[uid] = function () {
        delete delicious_callbacks[uid];
        callback();
    };
    url += "?jsonp=" + encodeURIComponent("delicious_callbacks[" + uid + "]");
    // add the script tag to the document, cross fingers
};

getDelicious(doSomething, "http://del.icio.us/feeds/json/bob/mochikit+interpreter");

The fetched URL from this hypothetical experiment would look something like this:

http://del.icio.us/feeds/json/bob/mochikit+interpreter?jsonp=delicious_callbacks%5B12345%5D

delicious_callbacks[12345]([{
    "u": "http://mochikit.com/examples/interpreter/index.html",
    "d": "Interpreter - JavaScript Interactive Interpreter",
    "t": [
        "mochikit","webdev","tool","tools",
        "javascript","interactive","interpreter","repl"
    ]
}])

See, because we're wrapping with parentheses, a JSONP request can translate into a function call or a plain old JSON literal. All the server needs to do differently is prepend a little bit of text to the beginning and wrap the JSON in parentheses!

Now, of course, you'd have libraries like MochiKit, Dojo, etc. abstracting JSONP so that you don't have to write the ugly DOM script tag insertion yourself, etc.

Of course, this just solves the standardization problem. Your page is still toast if the remote host decides to inject malicious code instead of JSON data. However, if implemented, it'd save a lot of developers some time and allow for generic abstractions, tutorials, and documentation to be built.

The JavaScript engine in Firefox has some really asinine warnings, here's the one that annoys me most:

deprecated with statement usage:

with ({stuff: "here"}) { eval("alert(stuff)"); }

Ok, now this is just lame. with is clearly in the ECMA standard and all JavaScript implementations, is definitely useful, and it can't go away while still maintaining backwards compatibility. It provides functionality that simply can't be offered any other way since you don't have access to the namespace objects from the script side of the interpreter.

Now I can hypothesize the reasoning for wanting to deprecate this syntax, but it's not necessary. I imagine that someone decided that with is slowing the whole language down since usage of it or eval basically requires a hash table (or equivalent) implementation of the function local namespace. Sure, that's true, but on a per-function basis.

If we assume that eval becomes a keyword at some point, they could simply mark functions that use either with or eval as needing a dynamic namespace. Everything else could use an optimized locals implementation (like Python's). The majority of JavaScript code can have a theoretically faster implementation, the rest stays the same speed, and nothing breaks. While you're at it, let us introspect local namespaces like Python allows with locals() so we can put together our own debugger without hacking the interpreter; Venkman is obnoxious.