WUI: view content in an HTML5 sandboxed iframe

[davidsarah]

Sandboxed iframes support loading content in a separate unique origin (when the allow-same-origin is not set). This solves many (not all) of the problems described in #615, for browsers that support it: Chrome, IE10+, and soon Firefox 17+.

Note that if we sandbox by default, that will affect the ability to save the raw version of files with in-browser-viewable MIME types served from Tahoe (because it will also save the framing page). To mitigate that we also need #827.

[davidsarah]

Note that HTML5 sandbox does not in any way require JS. Nor does it stop single-page JS webapps served from Tahoe from working, if allow-scripts is set in the sandbox tag. Multi-page JS webapps can also work if they do not rely on same-origin information sharing, although we might need to handle .css and .js filetypes differently because the browser will be expecting them to be served raw, not framed.

[davidsarah]

Grr, Chrome lost my comment. Will try to reconstruct:

Which permissions can we allow on an ​iframe sandbox attribute?

allow-same-origin:

• No, that would defeat the purpose of sandboxing for us.

allow-top-navigation: allow-popups:

• No, the navigated frame or popup would be outside the sandbox. The sandbox mechanism does not prevent an attacker from navigating directly to the unsandboxed content from their own site, but we want to prevent this from happening accidentally.

allow-scripts:

• Probably OK. We don't care if the sandboxed content can run scripts as long as they're in a unique origin. OTOH, this does potentially increase the attack surface for browser bugs.

allow-forms:

• Probably OK, but it's not clear to me what security property this is enforcing at all (since forms can in any case be submitted cross-origin).

[davidsarah]

Replying to davidsarah:

allow-top-navigation: allow-popups:

• No, the navigated frame or popup would be outside the sandbox. The sandbox mechanism does not prevent an attacker from navigating directly to the unsandboxed content from their own site, but we want to prevent this from happening accidentally.

Also, in the table ​here, we want a column that does not contain "master" or "top" in any row, so the iframe's "seamless" attribute also must not be set.

[davidsarah]

Implementing this via Content Security Policy rather than an iframe is much easier.

[freddyb]

Currently, it's very hard (and according to ​https://bugzilla.mozilla.org/show_bug.cgi?id=859454#c11 nearly impossible) to restrict a document to its frame and allowing scripts at the same time with iframe sandbox.

Once scripting is allowed, the document may use certain hacks to break out of the sandbox by unframing itself, thus being rendered in a shared origin (again).

Did you look at the paper "Privilege Separation in HTML5 Applications"(usenix security 2012)? Worth a read in this context: ​https://www.usenix.org/conference/usenixsecurity12/privilege-separation-html5-applications

[daira]

​https://bugzilla.mozilla.org/show_bug.cgi?id=785310 is just a bug in Mozilla's implementation. There's no spec ambiguity there; the spec does what we want.

[daira]

In other words, this is consistent with what I said about allow-scripts increasing attack surface for browser bugs ;-)