RE: ISSUE-166 html-sandboxed: Chairs Solicit Proposals

Hi all,

Resending this as I hit an issue with the mailing list server.

Thanks,

Jacob

-----Original Message-----
From: Jacob Rossi 
Sent: Friday, July 22, 2011 5:36 PM
To: Sam Ruby; HTML WG LIST
Cc: Adrian Bateman
Subject: Change Proposal: ISSUE-166: text/html-sandboxed does not always fail closed

ISSUE-166: text/html-sandboxed does not always fail closed
-------------------------------------------------------------------------------------------------------------
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.

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"

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 


 
> > -----Original Message-----
> > From: public-html-request@w3.org [mailto:public-html- request@w3.org]
> > On Behalf Of Paul Cotton
> > Sent: Sunday, July 24, 2011 8:25 AM
> > To: HTML WG LIST
> > Subject: RE: ISSUE-166 html-sandboxed: Chairs Solicit Proposals
> >
> > REMINDER: If no Change Proposals are written by July 28th,
> > 2011 this issue will be closed without prejudice.
> >
> > /paulc
> >
> > Paul Cotton, Microsoft Canada
> > 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> > Tel: (425) 705-9596 Fax: (425) 936-7329
> >
> >
> > -----Original Message-----
> > From: public-html-request@w3.org [mailto:public-html- request@w3.org]
> > On Behalf Of Sam Ruby
> > Sent: Tuesday, June 28, 2011 11:02 AM
> > To: HTML WG LIST
> > Subject: ISSUE-166 html-sandboxed: Chairs Solicit Proposals
> >
> > 'text/html-sandboxed does not always fail closed'
> >
> > Per the decision policy, at this time the chairs would like to solicit
> > volunteers to write Change Proposals.
> >
> > http://www.w3.org/html/wg/tracker/issues/166
> > http://dev.w3.org/html5/decision-policy/decision-
> > policy.html#escalation
> >
> > If no Change Proposals are written by July 28th, 2011 this issue will
> > be closed without prejudice.
> >
> > Issue status link:
> > http://dev.w3.org/html5/status/issue-
> > status.html#ISSUE-166
> >
> > - Sam Ruby
> >
> >
> >

Received on Monday, 25 July 2011 18:44:04 UTC