ChangeProposals/text html sandboxed

ISSUE-166: text/html-sandboxed does not always fail closed

Change Proposal submitted by Jacob Rossi (Microsoft)

SUMMARY:

The text/html-sandboxed MIME type [1] as specified has three significant issues:

1. The spec describes it as fail-closed in non-supporting browsers. This is untrue for certain legacy browsers.
2. It does not allow the server to set the individual sandboxed flags like the sandbox attribute can.
3. It does not allow content other than text/html to be sandboxed.

Originally, Microsoft offered a proposal [2] to use a MIME type attribute instead (solves issues #1 and #3). However, we were given feedback that Content Security Policy [3] has a better proposal that solves all three issues. We agreed with the feedback and implemented the sandbox directive for CSP in our latest preview of IE10.

Because better initiatives exist for server-directed sandboxing and because the current HTML5 specification has the three identified issue above, we propose that the text/html-sandboxed MIME type be removed from the spec altogether.

RATIONAL:

The sandbox attribute [4] can be used on an iframe to prevent content from your own domain from: having access to your storage, executing script, creating popups, submitting form data, etc. However, as the spec points out, it is possible that the sandboxed content could convince the user to navigate to the sandboxed content directly (not within an iframe). If this were to occur, then all restrictions would be off and the content has escaped the sandbox. Therefore, it's necessary that the server have a method of indicating the content should be sandboxed.

While implementing the sandbox feature, we investigated addressing the issue using the text/html-sandboxed MIME type. The first spec issue we found was that it indicates using this in combination with a .sandboxed file extension will provide fail-closed sandboxing--that is, browsers which do not support sandbox will fail to render the content. We found this to not be true in certain legacy browsers due to MIME type sniffing behaviors (see test case #1 below).

Second, the use of a MIME type means that the server can only provide a Boolean indication of sandboxing--either the content should be sandboxed or it should not. Conversely, the sandbox attribute provides a set of "allow-*" tokens that enable back certain privileges to the sandboxed content. It is a reasonable scenario that the content provider may know that the content should be sandboxed but that it needs a few extra capabilities (ex: needs to execute script)-- this feature disparity makes the MIME type seem broken.

Third, the text/html-sandboxed MIME type only allows for text/html content to be sandboxed. There are plenty of other types where sandboxing is useful (e.g., SVG, XHTML) and the above identified vulnerability still exists.

The emerging Content Security Policy proposal includes the ability for a server to specify a sandbox directive in an HTTP header. The header can be applied to any content type, can include any of the allow-* tokens applicable to the attribute, and is advertised correctly as a fail-open feature (similar to the sandbox attribute). We feel such proposals have a better chance of solving this problem more thoroughly. Because the feature as spec'd has several identified issues and no user agent has implemented the MIME type (to the best of our knowledge), we propose the text/html-sandboxed MIME type be removed from HTML5 altogether.

DETAILS:

1. In section 12.2 "text/html-sandboxed," remove the description of the text/html-sandboxed MIME type.
2. In section 4.8.2 "The iframe element," remove the text "To limit the damage that can be caused by hostile HTML content, it should be served using the text/html-sandboxed MIME type."
3. In section 4.8.2 "The iframe element," remove the text "Warning! It is important that the server serve the user-provided HTML using the text/html-sandboxed MIME type so that if the attacker convinces the user to visit that page directly, the page doesn't run in the context of the site's origin, which would make the user vulnerable to any attack found in the page."
4. In section 4.8.2 "The iframe element," remove the text "Note: Potentially hostile files can be served from the same server as the file containing the iframe element by labeling them as text/html-sandboxed instead of text/html. This ensures that scripts in the files are unable to attack the site (as if they were actually served from another server), even if the user is tricked into visiting those pages directly, without the protection of the sandbox attribute."
5. In section 4.8.3 "the embed element," remove the text "the embed element's Document was parsed from a resource whose sniffed type as determined during navigation is text/html-sandboxed"
6. In section 4.8.6 "the object element," remove the text "the object element's Document was parsed from a resource whose sniffed type as determined during navigation is text/html-sandboxed"
7. In section 2.1.1 "Resources," change " The term HTML MIME type is used to refer to the MIME types text/html and text/html-sandboxed" to be " The term HTML MIME type is used to refer to the text/html MIME type."
8. In section 3.1.3 "Resource metadata management," remove the text "or the resource was labeled as text/html-sandboxed"
9. In section 4.8.3 "the embed element," remove the bullet "The element's Document was not parsed from a resource whose sniffed type as determined during navigation is text/html-sandboxed (unless this has been overridden as described above)"
10. In section 5.3 "Origin," remove the bullet "If a Document was generated from a resource labeled as text/html-sandboxed. The origin is a globally unique identifier assigned when the Document is created."
11. In section 5.5.1 "Navigating across document" step 20, remove the bullet " 'text/html-sandboxed' Follow the steps given in the HTML document section, and abort these steps."
12. In section 11.3.1 "The applet element," remove the text "and when the element's Document was parsed from a resource whose sniffed type as determined during navigation is text/html-sandboxed"

IMPACT:

Positive Effects

1. Sandbox is not falsely advertised as fail-closed, which otherwise could cause web developers to have a false sense of security.
2. HTML5 doesn't maintain a feature which only partially solves the problem.
3. Other security-specific specification proposals are given the chance to solve this problem in a complete way.

Negative Effects

No major negative effects; to our knowledge no user agents have implemented text/html-sandboxed.

Risks

1. Other proposals (i.e., CSP) fail to finalize their solution to this issue.

REFERENCES:

1. http://dev.w3.org/html5/spec/iana.html#text-html-sandboxed
2. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12390
3. https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html
4. http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-sandbox

Test Case #1:

1. Create a page with the markup below.
2. Save the file with a .sandboxed file extension.
3. Configure your server to send text/html-sandboxed for the .sandboxed file extension.
4. Browse to the page.

<!DOCTYPE html>
<html>
	<head>
		<title>Sandboxed Content</title> 
	</head>
	<body>
		<p>If an alert is displayed, then the browser does not support the sandbox MIME type and has failed open.</p>
		<script>
		document.cookie = "somefakecookie=test; expires=Thu, 2 Aug 2012 20:47:11 UTC; path=/";
		alert(document.cookie);	
		</script>
	</body>
</html>	

In at least Internet Explorer 6.0, the content will be sniffed as text/html and rendered un-sandboxed. Therefore, the text/html-sandboxed MIME type is not fail-closed as advertised.