The sad state of DOM security (or how we all ruled Mario's challenge)

A few days ago Mario Heiderich posted second installment of his xssme challenges (viewable in Firefox only for now). But it wasn't a usual challenge. The goal was not to execute your Javascript - it was to get access to the DOM object property (document.cookie) without user interaction. In fact, the payload wasn't filtered at all.

My precious!

This goes along Mario's work on locking DOM and XSS eradication attempt. The concept is that server side filtering for XSS will eventually fail if you need to accept HTML. Further on - sometimes Javascript code should be accepted from the client (mashups are everywhere!), instead we want it to run inside a sandbox, limiting access to some crucial properties (location, cookie, window, some tokens, our internal application object etc.). That's basically what Google Caja tries to achieve server-side. But server does not know about all those browser quirks, parsing issues - it's a different environment after all.

So if a total XSS eradication is possible - it has to be client-side, in the browser.
Of course, this requires some support from the browser and the most common weapon is ECMAScript 5 Object.defineProperty() and friends. Basically, it allows you to redefine a property of an object (say, document.cookie) with your own implementation and lock it down so further redefines are not possible.

In theory, it's great. You insert some Javascript code, locking down your precious DOM assets, then you can output unmodified client's code which is already operating in a controlled, sandboxed environment - and you're done. In theory. Read on!

jQuery hijack plugin - nice addition to jQuery UI 1.7

I have just published a jQuery plugin that I've used with great success on many of my last projects - jQuery hijack. What hijacking is and why is it of any importance?

The amazing world of widgets

When loading a widget on a page, say tab or dialog, we are often loading its content from another URL via AJAX. This is a common technique and nothing new - we may e.g. use jQuery.load() or jQuery.tabs() from Jquery UI to achieve this. Let's say we are loading a table containing a product list to a tab. In this table we have some columns so we can sort it by clicking on a column header and page the results by using the pager links we developed.

What happens when we click on any link used to e.g. sort or go to next page in our loaded content? It replaces the whole page. The same thing happens when we have e.g. a search form within our tab content and we submit it. Although completely understandable (and there are many ways to avoid it), it's not exactly the best behavior. What can help you - is hijacking. jQuery hijack plugin was designed exactly to come to your rescue.

Hijacking to the rescue

Hijacking or hijaxing is a term used by Chris Thatcher a long time ago in a jQuery UI thread, where he proposed a way of capturing all the links within a widget content and making them reload only that widget. And this is exactly the core functionality of jQuery hijack plugin.

By using the plugin, we can call a simple one function jQuery.hijack() and voila - from now on, all links and forms are hijacked - so paging links in the tab will simply display another page of results in this tab, search form will also display results inline - everything requires only one line of code (usually).

More info

The plugin works flawlessly with jQuery UI widgets, like tabs or dialogs, I also heavily used it with jqModal plugin. This 1KB plugin also allows you to:

• skip hijacking some forms/links
• use click() handlers for links to skip following them at all
• skip submitting forms (validation)
• always run a particular function after reloading content (e.g. to init some objects)

I've created a demonstration page for plugin features where you can see it in action with jQuery UI. You may download the plugin at its Google code page. The plugin is dual licensed under MIT/GPL licenses.