WUI: view content in an HTML5 sandboxed iframe #1797

New Issue

tahoe-lafs · 2012-08-27T18:27:07Z

davidsarah commented

2012-08-27 18:27:07 +00:00

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.

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.

tahoe-lafs added the

labels 2012-08-27 18:27:07 +00:00

tahoe-lafs added this to the soon milestone 2012-08-27 18:27:07 +00:00

davidsarah commented

2012-08-27 19:02:35 +00:00

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 commented

2012-08-28 18:40:51 +00:00

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~~Possibly 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).

Grr, Chrome lost my comment. Will try to reconstruct: Which permissions can we allow on an [iframe sandbox attribute](http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element)? `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~~Possibly 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 commented

2012-08-28 18:42:39 +00:00

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.

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/1797#issuecomment-89391): > `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](http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context-names), 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 commented

2012-11-22 01:28:28 +00:00

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

freddyb commented

2013-04-15 11:04:57 +00:00

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

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 commented

2013-04-16 03:35:41 +00:00

(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.