Ladies and gentlemen of the jury,
In developing my markup templating system for Verbosio, it's becoming
clear that I need to add JavaScript support for documents parsed through
a DOMParser ("data documents").
At first, I need it for testing - data documents define the parameters
of the test, and I need to dynamically execute certain commands based on
the documents I'm working with. Soon, I'll need the same scripting
support for live use, in order to support event handlers for specific
events that happen in my application. In either case, some data
documents themselves (with XTF thrown in for good measure, until XBL 2
comes along) will provide scripts inline which I must evaluate.
What I'm wrestling with is whether or not to sandbox these scripts.
On the one hand, sandboxing is usually a good idea. On the other hand,
the scripts would be working with XUL and XTF elements, which the
application has graciously generated in a chrome, privileged
environment. By handicapping them within a sandbox, I may be
restricting what the template author can do with the (not data, but
chrome) user interface they're supposed to manipulate.
Consider a XUL tree, for example. With chrome privileges, the script
could provide a nsITreeView object for the tree directly. Without
chrome privileges, I'm not sure if it can even generate and maintain a
whole bunch of <xul:treeitem/> and <xul:treechildren/> elements for the
tree. It would need access to the XUL tree's DOM, and full permission
to add new elements to the tree.
Here's why I'm debating it, instead of just saying "sandbox it": These
data documents, in my current model, would come as part of a XULRunner
application's extensions. A chrome XUL overlay from the extension would
have the same power as an unsandboxed script: the user would be no more
vulnerable than they are from installing an extension.
On the other hand, if I switch to a model where these template data
documents are generally retrieved from a website, then of course I'd
want to sandbox them. Then, though, I'd have to use some "sandboxed
extensions model", which I'm not sure exists for general XULRunner
applications.
I'm looking for feedback on what the best route is: just how much trust
should I give scripts in these data documents, and if I should start
thinking about ways to keep the whole kit & kaboodle in a sandbox.
(Of course, there's the scary possibility that given a chrome element, a
template's XUL UI could insert a <xul:script/> tag into the chrome DOM.
I'm already thinking of stripping <html:script/>, <svg:script/> and
<xul:script/> elements from the template, but how else from the DOM can
I detect that a node could load a script? If I load the template's XUL
user interface into a content iframe with a data: URL, will it still
work, per the "disable remote XUL" bug?)
---
Footnote: Here's what I'm thinking the scripting element would look like:
<markup:script><![CDATA[{
// properties, methods, etc.
}]]></markup:script>
[scriptable, uuid(...)]
interface xeIMarkupScriptElement : nsISupports {
/**
* The JSObject generated from the script element's contents, or null
if a parsing error occured.
*/
readonly attribute nsIVariant scriptObject;
};
<xul:script>
// When I have a particular method to call
function callMethod(scriptElement, method, args) {
// argument checking first, of course, then:
return scriptElement.scriptObject[method].apply(scriptElement, args);
}
</xul:script>
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
