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

Re: XSS risk from iframe@doc?

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 17 Jan 2010 15:25:15 -0800
Cc: Philip Taylor <pjt47@cam.ac.uk>, Adam Barth <w3c@adambarth.com>, HTML WG <public-html@w3.org>
Message-id: <91C5A594-0839-4F85-94D1-4A603C62421F@apple.com>
To: Ian Hickson <ian@hixie.ch>

On Jan 17, 2010, at 1:11 PM, Ian Hickson wrote:

> 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.

Adam did specify "weak XSS filters". Even though filters based on blacklisting instead of whitelisting are poor design, I suspect a lot of sites still use them and therefore we might make existing sites more vulnerable.

Received on Sunday, 17 January 2010 23:25:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:57 UTC