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