- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 29 Jun 2012 23:03:49 +0000 (UTC)
- To: Sethu mathavan <siyan.mady@gmail.com>, Adam Barth <w3c@adambarth.com>
- Cc: whatwg@lists.whatwg.org
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. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 29 June 2012 23:04:20 UTC