Re: XSS risk from iframe@doc?

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