- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 07 Dec 2009 04:12:08 -0800
- To: gaz Heyes <gazheyes@gmail.com>
- Cc: sird@rckc.at, Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>, public-web-security@w3.org
- Message-id: <95AE2685-E231-4A83-A422-3227EB0BE160@apple.com>
On Dec 7, 2009, at 3:36 AM, gaz Heyes wrote: > 2009/12/7 Maciej Stachowiak <mjs@apple.com> > I see. So the premise is that if you can inject attributes onto an > input element (but not inject arbitrary content) and presumably > can't inject attributes into certain other elements which have auto- > firing event handlers (like <body> or <img>), then you now have a > drive-by XSS exploit using autofocus where previously some user > interaction would have been required. But how about this: > > <input style=position:fixed;left:0px;top:0px;width:100%;height:100% > onmouseover=alert(1)> > > Same conditions, essentially the same effect. Thus, I don't think > autofocus meaningfully increases attack surface. > > Well it enables attack where previously not possible, for example > consider a web site that filters user input to remove <>():& etc. we > can still auto execute javascript by supplying a vector such as:- > > "autofocus/onfocus="location=name"x=" You are correct that if the site filters :, ; and &, but not " and =, when validating attribute values, then there would be a new attack possible. That seems like a pretty thin sliver of additional attack surface. I believe : and ; are not considered especially dangerous in attribute values, certainly compared to " and =. They are very likely to be allowed if the injection vector is a user-supplied URL for instance. > Another point is a onmouseover needs to have the user's focus > whereas the vector I mentioned can be used within a hidden iframe > and enables automation of attack rather than requiring a user to > focus on each injection. The user does not have to take any action for "mouseover" to fire, other than to have their mouse somewhere in the content area. They don't even have to move the mouse after the load initiates. You are correct that this attack cannot be done in a hidden iframe loaded by a secretly malicious page. You could do it with an opacity 0 (or otherwise invisible) iframe layered over the whole page. Doing that amounts to clickjacking, though, so it could not happen if there is a client-side clickjacking defense. Although if there is framebusting or framing prevention, then the hidden iframe attack won't work either. My conclusion is that the extra XSS attack surface from limited content injection created by "autofocus" is quite small, probably not enough to really worry about. Regards, Maciej
Received on Monday, 7 December 2009 12:12:42 UTC