- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 6 Mar 2012 10:45:27 -0800
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? 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 Adam On Tue, Mar 6, 2012 at 5:58 AM, Sethu mathavan <siyan.mady at gmail.com> wrote: > Hi, > Im a professional application pentester. i developed and tested my own > html5 web application with iframes included in it. > > 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. > > > Regards, > Mady, > Application Pentester.
Received on Tuesday, 6 March 2012 10:45:27 UTC