Time to work on a Rec track JS sandbox? was: CSP and innerHTML

I pinged my Twitter followers for some thoughts on this... and the responses make me wonder if this isn't an area that we might put under the same thought space as how to secure Web Components, that is, by thinking about DOM sandboxes.  

I know there has is a lot of work in this area.  Gareth Heyes' jsreg (https://code.google.com/p/jsreg/) and MentalJS   (http://www.thespanner.co.uk/2012/10/18/mentaljs-sandboxparser/), the dominatrixss-csp project (https://code.google.com/p/dominatrixss-csp/) seems to be, at root, conceptually similar - hook DOM modification points and do filtering.  

ADSafe and Caja offer other approaches, and js.js yet another (http://sns.cs.princeton.edu/2012/04/javascript-in-javascript-js-js-sandboxing-third-party-scripts/) 

This seems like a much bigger project than adding a new directive in CSP.  

Is harmonizing and creating a W3C Recommendation-Track lightweight (less overhead than an iframe) sandbox something that we ought to consider adding to the WebAppSec charter?

On the one hand, it is clearly still an area of ongoing research and development.  On the other, there's actually quite a few years' of experience working with these concepts in the community now, and specs like Web Components that are in need of such a thing are progressing rapidly.

Very interested to hear thoughts on this.

-Brad


---------------

From: Eduardo' Vela [mailto:evn@google.com] 
Sent: Tuesday, April 30, 2013 12:10 PM
To: Hill, Brad
Cc: Carson, Cory; Ian Melven; WebAppSec WG
Subject: Re: CSP and innerHTML

Yes, that's a good analogy. We are not really concerned about traditional XSS, but more of jQuery-type of APIs being misused, which are mostly introduced by innerHTML being used instead of textContent/innerText, or being used for WYSIWYG editors and rich text fields.

Received on Thursday, 2 May 2013 17:48:39 UTC