[whatwg] Security Issue- Iframe Sandbox attribute - Clarity of operation

Ian Hickson ian at hixie.ch
Fri Jun 29 16:03:49 PDT 2012

On Tue, 6 Mar 2012, Sethu mathavan wrote:
> My code for iframe is <iframe src="xyz.htm" sandbox="">. Expected 
> working is that scripts in the "xyz.htm" should not be executed. 
> Normally,it works fine.
> But i was able to alter the sandbox attribute by intercepting and 
> modifying the the response with a proxy tool as follows: <iframe 
> src="xyz.htm" sandbox="allow-same-origin allow-scripts"> Now, browser 
> allows the script in xyz.htm to get executed and original functionality 
> is altered.
> The main purpose of implementing the sandbox attribute is to restrict 
> the contents within the particular frame. But that very purpose is being 
> compromised. This facilitates the Man-in-the-middle attack. Is this the 
> intended working of the attribute or is there any modifications planned 
> for the future? Need more clarification on this.

On Tue, 6 Mar 2012, Adam Barth wrote:
> The feature is working as intended.  If you can intercept and modify the 
> enclosing page, why not just insert a script block and XSS it directly?

I agree with Adam here.

> By the way, you might also be interested in the sandbox CSP directive, 
> which lets you apply a sandbox policy to a resource regardless of the 
> context in which it's used:
> http://www.w3.org/TR/CSP/#sandbox

Even with this, if you can do a man-in-the-middle attack, it provides with 
minimal to no protection.

If you are concerned with MITM attacks, TLS is the right solution.

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

More information about the whatwg mailing list