W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: XSS risk from iframe@doc?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 17 Jan 2010 12:31:08 -0800
Message-ID: <dd0fbad1001171231q23657ecdv69fd5b227108acf3@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: HTML WG <public-html@w3.org>
On Sun, Jan 17, 2010 at 11:41 AM, Adam Barth <w3c@adambarth.com> wrote:
> Whenever we add a new syntax for executing script, there is some risk
> that web sites with weak XSS filters will mistakenly let attackers
> inject scripting using the new syntax.  For example, a web site might
> let an attacker inject the following string:
>
> <iframe doc="<script>alert(1)</script>">
>
> The risk from this injection vector is mitigated because a
> regexp-based XSS filter will likely block the @doc attribute from
> containing HTML that executes script.  However, more advanced XSS
> filters that understand how to parse HTML attributes might let that
> string through.
>
> There area couple of options for resolving this issue:
>
> 1) Always give documents created with @doc a unique origin.  This
> approach is consistent with the use case of using this attribute for
> untrusted content.
>
> 2) Change @doc from being an HTML attribute to being a DOM method.
> This approach also makes it impossible for authors to screw up the
> escaping.

I was under the impression that @doc would only be valid when @sandbox
was around.  Thus you'd have to explicitly allow scripts in order to
fall prey to XSS, and you're stupid if you allow-scripts without
sanitizing the input somehow.

Generally, all the security problems of @doc are mitigated when used
in conjunction with @sandbox.  By default scripts can't run and it has
a unique origin.

~TJ
Received on Sunday, 17 January 2010 20:32:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC