W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2012

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

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 6 Mar 2012 10:45:27 -0800
Message-ID: <CAJE5ia9fxQQk=DnUj=j9yimPsJ+wy8pP0agGFT4O6MXCXw70uQ@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:40 UTC