I am cautiously (and shamelessly) launching a product called CliqueSafe, www.cliquesafe.com, which is a code execution prevention mechanism for JavaScript designed to prevent Reflected, Persistent and Self-XSS from succeeding in its goal: i.e. extracting information from a website and/or causing the website to manner not intended by the owner.

CliqueSafe is a client/server solution, which uses a "rewiter" script to password protect access to DOM methods that can modify a page, send or retrieve data directly (i.e. XMLHttpRequest) or indirectly (i.e. HTMLImageElement.src).

The rewriter deadlocks the protection using the latest ECMAScript standards for property setters/getters and maintains the anonymity of the password.

Deploying CliqueSafe is relatively straight forward, though certainly not a case of "drop it in and you're done".

Web pages employing CliqueSafe have to be modified so that any JavaScript containing calls to rewritten methods is served up by the CliqueSafe script server. Calls to rewritten methods are replaced with a CliqueSafe equivilent, which usually just means adding a placeholder for the password as an extra parameter. e.g. n.appendChild(node) becomed n.appendChild(node,"/*!param:hash*/"). /*!param:hash*/ is replaced by a session-linked password by the script server.

I have managed (after loosing much hair) to get the thing to deadlock on IE9, Firefox 6.0+, Chrome 18+ and Safari 5.1+. Nobody should ever knock IE9 again, of all the browsers it's the only one that full and properly supports the ECMAScript standards for property setters/getters!

CliqueSafe is, I think, the first of its kind. In my research I have found similar concepts to CliqueSafe that have come and gone and failed. These mechanism have all worked by creating a script loader, that sanitisies or rewrites the script as it is loaded by the webpage. These rather heavy weight mechanims offer no protection against Self-XSS and are vulnerable to many different kinds of reflected XSS. The difference with CliqueSafe is that it rewrites the language itself and does not need a loader. This makes it very lean and it protects against Self-XSS.

Interesting. A couple of initial questions; how is the password generated; does every user get a unique, static password generated when they install it? Also, what does this do that Content Security Policy doesn't?

-------------------------------------------------------
Research blog

A unique password is generated for each user, which is tied to their session. The system can be configured to generate a differnent password for each page refresh, though this would be at the cost of caching.

Regarding CSP:

There are a number of types of website where a content secuirty policy is inappropriate. Most notably mash-ups and social networks, where a large portion of the content is drawn from external sources. Such websites are completely vulnerable to attacks targetted at the modification of URL attributes, such as img/src.

The famous bin-laden facebook worm utilised a createElement and appendChild to insert a script element to download a larger script to do its damage. As CliqueSafe protects these functions, the bin-laden worm would no longer be viable.

Even websites that are protected by a content secuirty policy are vulnerable to XSS attacks aimed at exploiting their own API or fabricating AJAX calls. E.g. the facebook dislike worm, which used an XMLHttpRequest to craft a legitimate AJAX call to the FB API. The CliqueSafe mechanism protects XMLHttpRequest, so again, this worm would no longer be viable.

CliqueSafe allows API developers to force hackers to use the API propertly and therefore they can for the first time in Javascript history start to impose safe limits on what the API is allowed to do.

CliqueSafe came about because last year Facebook claimed to have solved a Self-XSS worm with a pop up warning if anyone tried to perform said self-XSS. I immediately investigated, thinking that they had managed to create something like CliqueSafe, only to discover that I could do what I pleased with Javascript, including replacing their logo with a picture of brighton pier. That's a bit rubbish, I thought and immediately set to work.

Even though the latest incarnations of browsers have locked down pasting javascript into the browser bar, there are still a number of successfull Self-XSS grooming attacks where users have been coaxed into in using the debug tools to run code. There are also a number of rogue browser addons, including in my opinion the Symantec addon for Chrome! So there is still enormous scope for self-XSS or client orginated code execution, all of which CliqueSafe protects against.

Does this answer your question?

Addendum:

It's also quite easy to extract information from a content secuirity policy website. For instance, say FB was CSP protected. I could create a bogus account and program a worm to send user's details to that account as an FB message. The FB mail system would then very kindly forward that information on to me. But, not if CliqueSafe was implemented, because if it were, I could lock down the API and prevent the bulk sending necessary for the worm to spread.