[dojo-contributors] dojox.secure

Kris Zyp kzyp at dojotoolkit.org
Wed May 28 20:03:04 EDT 2008


I have done further work on the dojox.secure project, and I wanted to share what I have now and see if there is any feedback the API, and security holes that people might be aware. First, the goals of dojox.secure:
1. Provide an infrastructure for loading untrusted (presumably cross-site) widgets, ads, and other code and run these components within page without allowing unrestricted access to the page's environment (cookies, DOM, and full JavaScript environment).
2. Provide a means for such untrusted widgets to safely interact with a subset of the DOM. Most untrusted code like ads, invariably needs to have some UI.
3. Provide a library/API with a reasonable set of features such that untrusted code can execute without necessitating large transfers of dependencies/libraries.
4. Work within the same JS environment so that data can easily be passed between trusted and untrusted code, and the expense of new JS environments (frames) is not incurred.
5. Provide an environment and API that others libraries can follow our lead on. Cross-site development is a much different arena than same origin development because widgets must work in foreign environments that may not have the same libraries loaded. I wanted the API to be something that could be reasonably standardized on at some point in the future for interoperable cross-site untrusted components.

The benefits of achieving these goals are that sites can load ads and build mashups without compromising security and without resorting to inflexible and expensive frames. Advertisers and service and widget providers can build components and ads easily with a decent API that can be included in various pages that may want protection from these components. dojox.secure achieves these goals by building sandboxes using several key components:
1. xhrPlugins - This is the XHR plugin architecture that allows developers to easily use the most appropriate cross-site mechanism to securely load untrusted cross-site resources.
2. ADsafe style object-capability validator. This validator ensures that loaded untrusted JavaScript can not access the global environment, it can only access objects that have been specifically granted to the sandbox.
3. Secure DOM facade. This is a DOM wrapper that only allows access to a provided element and it's children. Query operations and such are limited to this subset of the DOM. This performs checks on all innerHTML sets, DOM manipulation, and CSS to ensure that unsafe priviledge escalating code does not enter the DOM.
4. Safe Dojo Library - This is a safe subset of the Dojo library that can be used by the untrusted code. Safe versions of several otherwise unsafe, but very important functions are included such as query(). There are also some additional language functions that are provided to compensate for the language restrictions enforced by the object-capability validator.
5. Sandbox creator that brings all these components together so developers can easily load HTML or scripts and sandbox them within a single DOM element. The sandbox will also provides loading facilities for dependencies that these resources may have (scripts and css files) and safely loads and sandboxes them as well.

The current demo and the API that is available for untrusted code can be seen here:
http://sitepen.com/labs/code/secure/dojox/secure/tests/load.html
An example of creating the sandbox and loading untrusted code looks like:
var sandboxContainerElement = document.getElementById("sandbox");
var sandbox = dojox.secure.sandbox(sandboxContainerElement);
sandbox.loadHTML("http://some-shady-site.com/advertisement.html");

You can currently load HTML or JavaScript from the sandbox object (or directly execute preloaded JavaScript). Scripts can interact with their DOM subset using the provided "element" variable. I have also considered an alternate scheme where one could execute untrusted JavaScript which would return an object that would have a render(element) method that the container code could execute to display a widget within a provided element. I think this approach could be more organized and efficient, but less traditional in terms of how a script interacts with the DOM.

Let me know if anyone has any thoughts on this design.
Thanks,
Kris
  ----- Original Message ----- 
  From: Kris Zyp 
  To: dojo dev. 
  Sent: Monday, April 21, 2008 10:58 AM
  Subject: dojox.secure


  I have been working on experimental project to create a mechanism for securely running untrusted scripts with Dojo. This project uses ADsafe-like object-capability limiting in combination with a DOM facade. The idea is that an untrusted script can executed, but it will only have access to that part of the DOM (and it's descendants) that you provide it, and it won't be able to access the window object or other sensitive global objects (like cookies). Anyway, I presume that I don't have an airtight implementation yet, but I would love to have some help in trying to find holes in this security model, to see if this is going to work. I have created a test page, where you can enter a script and execute it and interact with the DOM, and see if you can access anything outside the provided sandbox:
  http://persevere.sitepen.com/jsclient/dojo/dojox/secure/tests/load.html
  This system does create limitations (several are noted on the page) on what you can do in JavaScript and with the DOM.

  This would be used in combination with some type of secure loading mechanism (proxy, cross-site XHR, XDR, postMessage, etc.), to load a script in text form, and then the secure loader would execute it. I think this may have some real potential, we could provide a means for untrusted widgets and ads to be securely loaded such that they couldn't mess with main page.

  Thanks,
  Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20080528/104fe67c/attachment.htm 


More information about the dojo-contributors mailing list