Security Considerations

This is a brief introduction to the security considerations to help you better understand the system.

Complete Isolation

The Sandbox can be considered a JavaScript Virtual Machine. Each instance of Sandboxed content is converted into a class factory that can be further independently instantiated multiple times. The Virtual Machine provides full isolation of namespaces including DOM access and properties. Under no circumstances should your code be able to manipulate the document or JavaScript language in any way that impacts other code on the page. To accomplish this, each Virtual Machine has its own scope.

Historically, one of the challenges with JavaScript and reusable libraries was the risk of namespace conflicts, especially within JavaScript. Libraries were colliding with each other as they attempted to extend the built-in JavaScript types, expose methods (e.g., the ubiquitious $ library function) and so on. To alleviate this, the Sandbox Virtual Machine provides every object its own isolated built-in objects. As you write your components, feel free to extend any native prototype or object for your own use.

The next challenge is with DOM namespace collisions. As you mash-up indepedent code, you previously had to guarantee your ID's were unique and your class names did not accidentally inherit from the surrounding page. The Virtual Machine allows you to freely use ID's without worry of conflict.

Last, the DOM tree is a shared resource across the entire page. Each node is a singleton with a shared property set. For example, if two independent functions assigned the onclick handler of the same node, the last assignment would win. The Sandbox Virtual Machine provides every instance their own unique access to the state of each node. There should be no risk that your code can impact the manipulated members of other code.

Ensuring this isolation is a key component of the Sandbox Virtual Machine's security model. This is one area that we would like help stressing the system. If you can create conflicts between instances, please let us know.

CSS and Visited Hyperlinks

The CSS visited pseudo-class is considered a potential security risk by many experts. By combining the visited pseudo-class with the ability to examine the calculated style, you can determine whether a user has ever visited a specific hyperlink. Even without access to the calculated style, the URL-based properties enable the ability to associate a network request with a specific hyperlink. The Sandbox protects against both of these exploits with minimal impact on the user experience. The visited pseudo-class is supported for all CSS properties except for those that take a URL. Attempting to specify a URL (e.g., background-image) on a visited pseudo-class will be ignored (the value is switched to “inherit”). Attempting to retrieve a calculated value on a hyperlink will always return the non-visited value. This could create side effects in the rare case you are positioning elements based on the visited state as the position will be returned as if the hyperlink was not visited.

Below is an illustration of the visited hyperlink protections. Make sure to either add the URL of a site you visited or navigate to one of the pre-listed URLs. The hyperlink should render in the visited color (red). However, whenever code attempts to retrieve the color, the unvisited color (navy) will be returned to prevent any leakage of the user's browsing history.

<html>
    <head>
        <title>Visited Link Example</title>
        <link href="http://www.websandbox.org/Images/favicon.ico" rel="icon" />
        <style>
            a {color: navy}
            a:visited {color: red}
        </style>
    </head>
    <body>
        <p>blue: Unvisited Hyperlinks;<br>Red: Visited Hyperlinks </p>
        <ul id="list">
            <li><a target="_blank" 
                    href="http://www.microsoft.com">http://www.microsoft.com</a>
            </li>
            <li><a target="_blank" 
                    href="http://search.live.com">http://search.live.com</a>
            </li>
            </ul>
            <input type="text" id="URL" value="http://livelabs.com">
        <input type="button" onclick="AddUrl()" value="Add URL">
        <p><input type="button" onclick="DisplayStatus()" value="Try to retrieve visited status (color)"></p>
        <div id="output"></div>
        <script>
        function AddUrl()
        {
            var elLink = document.createElement("li");
            var el = document.createElement("a");
            el.target = "_blank";
            el.innerText = el.href = document.getElementById("URL").value;
            elLink.appendChild(el);
            document.getElementById("list").appendChild(elLink);
        }
        function DisplayStatus()
        {
            // This only returns hyperlinks in your scope
    	    var elLinks = document.links;
    	    var strStatus = "";
    	    for (var i=0;i<elLinks.length;i++)
    	    {
		        var el = elLinks[i];
		        strStatus += el.href + ":" + getComputedStyle(el,null).getPropertyValue("color") + "<br>"
	        }
	        document.getElementById("output").innerHTML = strStatus
        }
        </script>
    </body>
</html>

Feel free to experiment with additional CSS properties using the above example. All CSS properties should be properly protected against visited leakage.

Standard Exception Handling

The Sandbox supports JavaScript’s standard approach to error handling. This includes support for security exceptions. If you are attempting an operation that may be at risk of a security exception (this may be more likely as additional host-specific capabilities are exposed), you can protect your code as follows:

“Eval”uating Arbitrary Code

The Sandbox only supports evaluating JSON structures. JSON structures can be evaluated via either the eval method or standard JSON.parse API. Any attempts to evaluate a non-JSON structure will throw an exception. Below highlights a few of the unsupported evaluation equivalents. All of the following will generate a security exception (caught by the QOS layer) when executed:

We have discovered that many developers using timers make a common mistake of evaluating a constant value. If we discover this during the parsing process, we will (in a future update) extract the constant and re-wrap it as native code. This is enabled as a convenience for broader compatibility. In general, there are very few legitimate cases for arbitrary code evaluation. In many cases, your code can be rewritten so that it will not rely on this feature.

For example, instead of specifying the timer as a string, use a function:

Cross-Site Request Forgery

This work is not yet complete.

We will add protections preventing Sandboxed code from creating forms and hyperlinks that point back to the host site's domain. Since the code executes within the same domain as the host site, this is necessary to ensure cross-site request forgery protections cannot be bypassed.

We are going to add additional protections to prevent components from specifying forms and URLs that point back to the host site.

Overview

Using the Sandbox

Hosting the Sandbox

The Architecture