Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
On Tue, Dec 2, 2014 at 6:04 PM, Boris Zbarsky wrote: > Actually, sandboxing iframes of your own site is one of the main sandbox use > cases: it allows limited user upload of content without creating security > holes, in theory. No it is not, only if you use it in combination with srcdoc you are safe. Otherwise an attacker could trick the user to navigate directly to the file and steal cookies or origin-bound data. (The solution here is to finally fix the clipboard stuff. I believe both Gecko and Chrome have similar plans to address this case judging from their mailing lists. It would be good if those discussions moved into a spec space.) -- https://annevankesteren.nl/
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
> > Actually, sandboxing iframes of your own site is one of the main sandbox > use cases: ... Oh, hehe. ... it allows limited user upload of content without creating security > holes, in theory. Then let us hope that such content creation/collection/uploading doesn't require the use of Flash/Java/etc., eh? :) Sincerely, James Greene On Tue, Dec 2, 2014 at 11:04 AM, Boris Zbarsky wrote: > On 12/2/14, 8:01 AM, James M. Greene wrote: > >> So, it sounds like sandboxed iframes will probably /never/ support >> plugin instantiation -- even if such a plugin were hosted on the same >> origin as both the iframe page /and/ top-level page. >> > > For Gecko it depends. > > For example, we plan to ship a PDF viewer plugin (based on pdf.js) that we > may decide to allow in sandboxed iframes. Will need to audit it a bit. > > For third-party plug-ins, I suspect the "never" answer is a good > assumption for now. > > This mostly makes sense to me as you would only infrequently want to >> sandbox an iframe of your own site >> > > Actually, sandboxing iframes of your own site is one of the main sandbox > use cases: it allows limited user upload of content without creating > security holes, in theory. > > -Boris >
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
On 12/2/14, 8:01 AM, James M. Greene wrote: So, it sounds like sandboxed iframes will probably /never/ support plugin instantiation -- even if such a plugin were hosted on the same origin as both the iframe page /and/ top-level page. For Gecko it depends. For example, we plan to ship a PDF viewer plugin (based on pdf.js) that we may decide to allow in sandboxed iframes. Will need to audit it a bit. For third-party plug-ins, I suspect the "never" answer is a good assumption for now. This mostly makes sense to me as you would only infrequently want to sandbox an iframe of your own site Actually, sandboxing iframes of your own site is one of the main sandbox use cases: it allows limited user upload of content without creating security holes, in theory. -Boris
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
OK, those answers are all about what I expected, particularly the note about securing the API surface of Flash. So, it sounds like sandboxed iframes will probably *never* support plugin instantiation -- even if such a plugin were hosted on the same origin as both the iframe page *and* top-level page. This mostly makes sense to me as you would only infrequently want to sandbox an iframe of your own site, though it does seem to present a gap as, if I *did* want to sandbox an iframe of my own site, it would probably be to do something more like preventing top-level navigation and/or popups rather than to prevent the instantiation of personally-built plugins... but I cannot achieve the former without implicitly suffering the latter. Not critical but slightly frustrating until the HTML Clipboard API (for which ZeroClipboard is the best interim solution) eventually gets polished and implemented more widely. Sincerely, James Greene On Tue, Dec 2, 2014 at 9:49 AM, Boris Zbarsky wrote: > On 12/2/14, 7:46 AM, James M. Greene wrote: > >> 1. Is there any existing way or guidance for browser vendors on how to >> confirm that a plugin can be "secured" and thus allowed to be instantiated >> within a sandboxed iframe? >> > > As far as I know, there is not. For Gecko there definitely is not. > >2. Is there any existing way or guidance for library/plugin developers >> on >> how to provide appropriate metadata to the browser in order to allow a >> plugin to be considered "secured" and thus allowed to be instantiated >> within a sandboxed iframe? >> > > Again, as far as I know there is not. > >3. Is this really just confusing/misleading text that may never actually >> correlate to a real implementation? >> > > The text is intended to allow people to develop such systems if they want > to. I don't think any current UAs particularly want to. > > Note that making sure something with the API surface of Flash is "secured" > would be quite an undertaking... > > -Boris >
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
On 12/2/14, 7:46 AM, James M. Greene wrote: 1. Is there any existing way or guidance for browser vendors on how to confirm that a plugin can be "secured" and thus allowed to be instantiated within a sandboxed iframe? As far as I know, there is not. For Gecko there definitely is not. 2. Is there any existing way or guidance for library/plugin developers on how to provide appropriate metadata to the browser in order to allow a plugin to be considered "secured" and thus allowed to be instantiated within a sandboxed iframe? Again, as far as I know there is not. 3. Is this really just confusing/misleading text that may never actually correlate to a real implementation? The text is intended to allow people to develop such systems if they want to. I don't think any current UAs particularly want to. Note that making sure something with the API surface of Flash is "secured" would be quite an undertaking... -Boris
[whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
I have recently begun receiving issue reports about my JavaScript library, ZeroClipboard, not working in some common developer websites such as JSFiddle, CodePen, etc. The common thread here is that the problematic sites all host their snippets within sandboxed iframes... but ZeroClipboard relies on a seamless integration of a small Flash object. I eventually tracked this back to the iframe's `sandbox` attribute not allowing plugins to be instantiated [1] due the always-on sandboxed plugin browsing context [2]. When reviewing the HTML spec on both W3C and WHATWG, I found that this is *supposedly* not 100% accurate as there is a *suggestion* that a plugin can *somehow* identify itself as *secured* and thus still be allowed to instantiate within a sandboxed iframe [3][4][5]. However, from practical experience, I also believe that none of today's existing browser vendor implementations of iframe sandboxing take such a concept into consideration. >From [5]: A plugin can be *secured* if it honors the semantics of the sandbox > attribute. *For example, a secured plugin would prevent its contents from > creating pop-up windows when the plugin is instantiated inside a sandboxed > iframe.* So, back to today's reality, my questions for clarification are: 1. Is there any existing way or guidance for browser vendors on how to confirm that a plugin can be "secured" and thus allowed to be instantiated within a sandboxed iframe? 2. Is there any existing way or guidance for library/plugin developers on how to provide appropriate metadata to the browser in order to allow a plugin to be considered "secured" and thus allowed to be instantiated within a sandboxed iframe? 3. Is this really just confusing/misleading text that may never actually correlate to a real implementation? I tend to think not as I did manage to find some revision history that shows that the spec used to say that plugins were outright prevented/disabled rather than "secured" within iframe sandboxes. However, I also have not found any related discussion/guidance/etc. about how to move forward with "secured" plugins. *References* [1]: http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/#granular-control-over-capabilities [2]: https://html.spec.whatwg.org/multipage/browsers.html#sandboxed-plugins-browsing-context-flag [3]: https://html.spec.whatwg.org/multipage/embedded-content.html#sandboxPluginEmbed [4]: https://html.spec.whatwg.org/multipage/embedded-content.html#sandboxPluginObject [5]: https://html.spec.whatwg.org/multipage/infrastructure.html#concept-plugin-secure Sincerely, James Greene
