This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I propose that an "allow-plugins" option be added for the iframe sandbox attribute similar to the "allow-scripts" and "allow-forms" options. When included in the sandbox attribute value, the nested browsing context would be allowed to instantiate plugins. The specification text should be changed from: "The sandboxed plugins browsing context flag" to: "The sandboxed plugins browsing context flag, unless the sandbox attribute's value, when split on spaces, is found to have the allow-plugins keyword set" I am currently working on a kiosk application and want to prevent content rendered in an iframe from being able to open new windows or tabs that are outside of the control of the kiosk application. The sandbox attribute (when fully supported) seems like a perfect solution, except that many of the sandboxed pages (which may be out of our control) will have flash content. I realize that allowing plugins in sandboxed iframes opens a wide hole, potentially making the sandbox completely ineffective. However, for my use case I do not think the risk is that severe. I have a certain amount of control over what pages are navigated to. I also have control over which plugins are installed. I am more concerned with window.open and the target attribute than I am with flash or a quicktime video doing something malicious. In short I would like to be able to do something like: sandbox="allow-scripts allow-forms allow-plugins" to allow the sandboxed page to render fully (including flash and other plugin-based content), while still preventing the common methods of opening new windows/tabs. Even with the security risk, I believe the option should available so the developer can make the determination. Thank you for your consideration.
What is the purpose of having a sandbox if you allow all possible plugins in it?
The point is that the sandbox will still prevent the most common methods of opening new windows/tabs. A rogue plugin could still do something malicious, but as I mentioned, I'm working on a kiosk application where the plugins installed can be controlled. My use case is that I want to restrict creation of new windows/tabs, but I also want to be able to render flash content. The only plugins installed on the kiosk would be flash and a plugin for video (probably totem plugin on our standard linux installs). Maybe I'm missing something, but I believe the risk to my application from allowing those plugins would be small. I would be no worse off than not having the sandbox at all, and would be better in most cases since I would avoid problems with target and window.open calls.
Our focus here is really websites that are meant to be usable on all browsers, not content that's intended to be used only by specific computers. Your use-case doesn't *need* standardization, although it would make life easier for you -- you could conceivably write a browser extension, for instance. So it's unlikely that a solution would be accepted here if it's not suitable for general-purpose web use. What this ideally means is we'd work out some way for plugins to tell the browser that they understand sandboxed iframes and will respect their constraints, and then we would say that browsers can only load such plugins. However, even for web uses it's true that sandbox becomes much less useful today if you can't load Flash. E.g., one major use-case is to sandbox ads, but ads are often Flash. So maybe as an alternative, to allow quicker adoption of sandbox, we could somehow allow authors to specify which plugins they want to allow?
I like the idea of allowing authors to specify which plugins they will allow. Even if your first suggestion of only loading "safe-plugins" is implemented it may still be a good idea to allow authors specify the types of allowed plugins. We could scrap my suggestion of adding "allow-plugins" and instead create a new attribute that would white list plugins based on mime-types. So if I wanted an iframe to allow flash and video I could do something like: <iframe src="..." sandbox allowplugins="application/x-shockwave-flash video/mpeg"></iframe> One thing I don't like about this is that the new attribute depends on the sandbox attribute. We could potentially list the allowed mime types in the sandbox attribute directly, but I don't think that would be as clear as having a separate attribute. While it is true that my use case is just one specific example, I believe that it demonstrates a need in the sandbox feature. Your example of sandboxing ads is another. Another may be mash-ups where video (non-HTML5) or flash content is embedded. Intranets could be another example of a controlled environment where this capability may be useful.
Allowing even Flash inside the sandbox would make the sandbox meaningless. Flash (or any plugin) is binary executable code and therefore is free to do what it wishes--including violating your use-case by creating new popups.
Agreed. What I do think we should do is to make it clear that plugins are allowed to run in the sandbox, as long as the browser is sure that it satisfies the restrictions put upon the sandbox. So for example if it was possible for the browser to tell Flash that it's not allowed to run script and not allowed to navigate any parent frames, and those are the only restrictions placed on a given sandbox, then the browser could run flash.
(In reply to comment #6) > Agreed. > > What I do think we should do is to make it clear that plugins are allowed to > run in the sandbox, as long as the browser is sure that it satisfies the > restrictions put upon the sandbox. > > So for example if it was possible for the browser to tell Flash that it's not > allowed to run script and not allowed to navigate any parent frames, and those > are the only restrictions placed on a given sandbox, then the browser could run > flash. Related to this: <https://wiki.mozilla.org/Plugins:SandboxedPlugins>
(In reply to comment #6) > What I do think we should do is to make it clear that plugins are allowed to > run in the sandbox, as long as the browser is sure that it satisfies the > restrictions put upon the sandbox. > > So for example if it was possible for the browser to tell Flash that it's not > allowed to run script and not allowed to navigate any parent frames, and those > are the only restrictions placed on a given sandbox, then the browser could run > flash. That works for me. From the link posted by Julian it appears that there are already discussions for modifying the plugin API to support this. One other use case: It appears that Google used the sandbox attribute with their image search for a time, but apparently removed it because of the plugin problem. See: http://www.google.com/support/forum/p/Webmasters/thread?tid=4ab960cdb10c9aad&hl=en
mass-move component to LC1
(In reply to comment #7) > (In reply to comment #6) > > Agreed. > > > > What I do think we should do is to make it clear that plugins are allowed to > > run in the sandbox, as long as the browser is sure that it satisfies the > > restrictions put upon the sandbox. > > > > So for example if it was possible for the browser to tell Flash that it's not > > allowed to run script and not allowed to navigate any parent frames, and those > > are the only restrictions placed on a given sandbox, then the browser could run > > flash. > > Related to this: <https://wiki.mozilla.org/Plugins:SandboxedPlugins> Even with this kind of approach, I don't see how you can guarantee security. What stops an attacker from creating a plugin which claims support for sandboxing but doesn't in reality?
If the attacker can get the user to install a malicious plugin, they can run arbitrary code already. As long as that's the case, it doesn't hurt anything extra that the plugin also breaks out of sandboxes. If the plugin is some special type of restricted plugin that can't run arbitrary code and can only communicate with the browser and system through well-defined APIs, then those APIs could be designed such that it's not able to break out of sandboxes either.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>. Status: Rejected Change Description: no spec change Rationale: Bug 13267 makes a specific suggestion that could be made to work. Just allowing plugins is not a good a solution.