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

Re: XSS risk from iframe@doc?

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 17 Jan 2010 21:11:53 +0000 (UTC)
To: Philip Taylor <pjt47@cam.ac.uk>
Cc: Adam Barth <w3c@adambarth.com>, HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.1001172110040.3759@ps20323.dreamhostps.com>
On Sun, 17 Jan 2010, Philip Taylor wrote:
> Ian Hickson wrote:
> > On Sun, 17 Jan 2010, Adam Barth 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>">
> > > 
> > > [...]
> > 
> > doc="" is only meant to be used with sandbox="". I can just make it not do
> > anything at all if sandbox="" isn't specified, if that helps.
> 
> An XSS filter that lets the user give a doc attribute will let the user give a
> sandbox attribute too, i.e. they can write
> 
>   <iframe doc="<script>alert(1)</script>" sandbox="allow-scripts">
> 
> So as far as I can see, making it do nothing when there's no sandbox attribute
> doesn't help.

My bad, I misunderstood the attack vector you were describing. I thought 
you meant the attacker was inserting into doc="", not that he was 
inserting an <iframe>.

Frankly, any XSS filter that allows arbitrary unknown attributes and 
<iframe>s is pretty much doomed anyway. This is why XSS filters _must_ 
exclusively whitelist to be considered even remotely safe.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 17 January 2010 21:12:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:58 GMT