Re: text/sandboxed-html

Hi Ian and folks,



I just learned about this mailing list. Great to see all the fun discussions!



Letting web servers indicate the MIME type definitely improves the current sandbox design as long as MIME sniffing is not in the way. That is a legacy UA does not recognize the sandbox MIME type and then it sniffs and renders the content as text/html, elevating the privilege of the sandboxed content as a result.



Also, the deployment hurdle is that web servers must correctly mark the MIME type for sandboxed content. This could be a tall order.



I wrote a revision to our original MashupOS sandbox proposal [1] to retain the basic sandbox semantics while eliminating web servers setting the sandbox MIME types. I am attaching my writeup below. We use a "SANDBOX" tag rather than a "sandbox" attribute of an iframe so that legacy UAs will not be able to render the content with higher privileges. Must we piggy-back the iframe tag?



                                                      Thanks, Helen





---- attachment below ----
Sandboxes
Contents

  1.  Why sandbox
  2.  The SANDBOX element
  3.  Implementation guideline
  4.  Don't overload <iframe> with security restriction
1. Why SANDBOX
HTML content in a window or frame runs with the privilege of its "src" domain, allowing the script within to access the "src" domain's DOM objects including cookies and issuing XMLHttpRequest to its backend server.
Script content runs with the privilege of its enclosing page's domain.
Sandbox content runs with the privilege of no one. Namely, the content within cannot access any domain's DOM objects including cookies nor invoking XMLHttpRequest.
Sandbox is useful for constructing robust client mashups. Most of today's client mashups use third-party scripts for service components. Sandboxes enable mashup authors to create robust and secure client mashups of scripts without sacrificing the programming convenience of library function invocations. For each third-party library that a mashup uses, the mashup can generate a piece of sandbox content containing the library and add to the sandbox its needed display DOM elements such as <div>. The mashup can then access and mash up content across its sandboxes as it wishes without worrying about any of the libraries maliciously or recklessly tampering with the mashup's content or other resources.
Sandbox is also useful for containing and restricting third-party content, such as user profiles in social networking web sites. When sandboxed, such third-party content can contain richest possible content like script without the ability of accessing its host's resources like DOM objects including cookies and remote data access. In this way, sandbox can serve as a defense against cross-site scripting (XSS) attacks and disallow content from an untrusted source to run with the privilege of its host page.  While it is possible to host third-party content on a separate domain and use frames for isolation, sandbox eliminates the need of creating a new domain.
Different treatment of third party content is also demanded in the context of Web spam. Google announced in early 2005<http://googleblog.blogspot.com/2005/01/preventing-comment-spam.html> that hyperlinks with a rel="nofollow" attribute would not influence the link target's PageRank. Sandbox alleviates the burden of a site to annotate each hyperlink of third-party content by including the entire third-party content into a sandbox.

2. The SANDBOX element
  <SANDBOX src="foo.js" name="aSandbox" allow="forms" >
     Put the content here for browsers which do not support SANDBOX
  </SANDBOX>

The SANDBOX<http://www.w3.org/TR/REC-html40/interact/scripts.html#edef-SCRIPT> element contains at least a script indicated by the "src" attribute. The file indicated by "src" can only be a script. This can be easily validated by its corresponding script engine. The original MashupOS sandbox proposal [1] also allowed HTML and other types of content. The reason of this revision is to not requiring web servers to indicate MIME types, and therefore making it easier to deploy.
The host page can insert additional HTML elements into the sandbox through scripting, for example, through aSandbox.createElement(). These additional elements will be subject to the sandbox restriction.  The host page of a sandbox can directly invoke sandboxed functions aSandbox.map.setCenter(...). The invocation is in the context of the sandbox. The arguments passed to the sandbox must be of a primitive type. If an argument is not of a primitive type, its access by sandboxed code will throw an exception. This ensures that sandboxed code will not follow any references out of the sandbox.
Sandboxed code cannot access objects from outside the sandbox. Any such access throws an exception.
The sandbox can communicate with its host page and other iframes through PostMessage.
By default, the sandbox cannot contain any nested iframes or forms or plugins. The reason for denying iframes is primarily because any nested iframes can navigate the top level window in today's browsers. We think this navigation capability is dangerous since this improperly embraces transitive trust in the web: when "a.com" nests a "b.com" iframe, it trusts that no descendant iframes of "b.com" will tamper with (and navigate) the top level window. If one day, the nested cross-domain frames become unable to touch the top level window, it would be fine for the sandbox to nest cross-domain iframes. The iframe would not subject to the sandbox restriction, but would be rendered with the privilege of the domain indicated in "src" and the sandboxed code could not access the frame content. Sandboxed code could only navigate the iframes created by the sandbox.
3. Implementation guideline
The SANDBOX has a separate DOM document tree. We suggest implementing an interposition layer, a proxy wrapper, between DOM objects and JavaScript engine. This proxy wrapper serves as a reference monitor. Any DOM object access goes through this wrapper. Since any interactions between untrusted (sandboxed) and trusted content involve DOM object access, such accesses will go through the proxy wrapper, which can reliably tag an object to be from trusted or untrusted content. When a sandboxed function is invoked, any access to trusted objects is denied with an exception.
4. Don't overload <iframe> with security restrictions
It is undesirable to overload iframe tags with security restrictions as in <iframe security="restricted"> and <iframe sandbox="...">.

This is because new browsers must co-exist with legacy browsers. In legacy browsers, such additional restrictions do not exist and result in the content having more privilege than what its programmer intended.

Another problem with this approach is that when the restricted content is rendered with an iframe tag without the sandbox or restricted attribute (say by an attacker page), the restricted content will be rendered with the full privilege of the host site of the restricted content.



[1] Protection and Communication Abstractions for Web Browsers in MashupOS

Helen J. Wang, Xiaofeng Fan, Collin Jackson, and Jon Howell

21st ACM Symposium on Operating Systems Principles (SOSP), Stevenson, WA, October 2007