[whatwg] sandboxing scripts

Thu Dec 15 21:48:36 PST 2005

On Thu, 15 Dec 2005 19:11:13 +0600, Hallvord R M Steen  
<hallvors at gmail.com> wrote:

> Just playing around with ideas for other security models for SCRIPT.

Your ideas seem reasonable. JS security is something that has been long  
awaiting to be addressed.

> Here's what I thought: a new attribute "sandbox" (or "securitypolicy",
> name doesn't matter much) might tell the UA something about what the
> script can do:
> <script src="..." sandbox="writeonly">
> <script src="..." sandbox="none">

1. The entire thing has to degrade SAFELY in existing browsers. With your  
approach, any existing browser will just ignore the unknown "sandbox"  
attribute, effectively allowing the script to do anything. This is not  
acceptable.

2. The site author has to take care that the "sandbox" attribute is  
included in every <script> element, even in user-supplied code.

3. There are still HTML attributes like "onclick", and javascript: URIs  
that are not addressed.

> In all cases the limitation would apply only to the thread created by
> that SCRIPT tag. Functions defined in those scripts might be called
> later and would run with normal privileges.

This is dangerous, too, because a malicious script can try to redefine  
common JS functions like window.alert() to do something bad.

Here is my idea, then.

The primary danger of JS is that when different kinds of a single HTML  
page come from different sources (are authored by different persons). As a  
real life example, I'll take LiveJournal.com, where it's currently  
completely forbidden to include any scripts in journal entries or  
comments. They would like to allow some scripting, only if they could  
somehow separate harmless scripts from potentially dangerous ones.

The idea is to add a new element, <sandbox> (the actual name doesn't  
matter much). This element can appear anywhere (in both <head> and <body>)  
and can include any elements that it's direct parent can include. It has  
no other effect on its contents than altering the contained scripts'  
security. Everything enclosed in <sandbox>...</sandbox> is somewhat  
limited in what scripts can do.

1. All scripts inside <sandbox> are affected. This includes <script>,  
javascript: URIs, "onclick" etc. Other active objects like <object> that  
can access DOM are affected too (for example, Flash is restricted by  
<sandbox>, too).

2. The script in a <sandbox> thinks that it's god. It can do everything,  
but only inside that sandbox.

2.1. The window.document actually represents the part of document inside  
<sandbox>. Yes, it's not a valid HTML document -- with fake body element  
(window.document.body being the document fragment inside <sandbox>), and  
otherwise looking strange, but it's usable by most scripts. Other DOM  
facilities also pretend that there's nothing outside the sandbox.

2.2. If the <sandbox> has a domain="..." attribute, then the scripts  
inside the sandbox have access to cookies from the specified domain, can  
interact with other sandboxes and frames from that domain, and are  
otherwise restricted in a similar way as a regular content from that  
domain (but not breaking out of 2.1 restriction). The "domain" attribute  
can only specify the domain of the containing document or a subdomain  
thereof. (For example, LiveJournal can specify synthetized subdomains like  
<user>.livejournal.com for entries by each user.) If there is no "domain"  
attribute, then the inner JS doesn't have access to any cookies.

2.3. The JS namespace in a sandbox is isolated. JS inside the sandbox  
cannot see the variables and functions declared outside, and vice versa.  
JS outside the sandbox can accesss JS variables and functions from inside  
the sandbox in an explicit way (like sandboxElement.sandbox['variable']).  
If the outer JS needs to make several things (DOM nodes, JS variables)  
 from the outside accessible to the inner JS, it can do so by putting  
references to these into sandboxElement.sandbox array.

2.4. Multiple sandboxes on one page sharing the same "domain" attribute  
value share the same JS namespace (sandboxElement1.sandbox ==  
sandboxElement2.sandbox). Sandboxes without a "domain" attribute are  
always isolated.

3. Sandboxes can be nested, with each inner one being additionally  
restricted by the outer.

4. The script can find out that it's running in a sandbox. There's nothing  
bad about it.

5. There should be a discussion about what a sandboxed script can do. Can  
it set window.location? Can it do window.open()? Maybe these permissions  
should be governed by additional attributes to <sandbox>.

6. A sandbox can specify a single JS error handler for all enclosed  
scripts (to address known cases of scripts which are not ready for the  
unusual environment they are in).

7. Backward compatibility. The current browsers will ignore the unknown  
<sandbox> element and give the enclosed scripts full access to everything.  
This is not acceptable. As there is no way to disable scripting inside a  
certain element in HTML 4, the HTML cleaners usually found on sites live  
LiveJournal.com are still required. Here's what they should do.

7.1. There are new elements: <safe-script>, <safe-object>, <safe-iframe>  
(did I forget something?). They are equivalent to their "unsafe"  
counterparts, except that the existing browsers simply ignore them. HTML  
cleaners should replace <script> with <safe-script> and likewise.

7.2. HTML event handler attributes are mangled likewise: safe-onclick, for  
example. Note that this doesn't affect the names of DOM properties like  
element.onclick.

7.3. A new URI scheme is introduced: "safe-javascript:". Likewise.

-- Opera M2 9.0 TP1 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station at SW-Soft, Inc. [ICQ: 115226275]  
<alexey at feldgendler.ru>