- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 17 Jan 2010 15:25:15 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: Philip Taylor <pjt47@cam.ac.uk>, Adam Barth <w3c@adambarth.com>, HTML WG <public-html@w3.org>
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. Regards, Maciej
Received on Sunday, 17 January 2010 23:25:52 UTC