[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