- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 07 Dec 2009 02:53:18 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Ian Hickson <ian@hixie.ch>, sird@rckc.at, public-web-security@w3.org
On Dec 6, 2009, at 8:22 AM, Adam Barth wrote: > On Sun, Dec 6, 2009 at 1:21 AM, Ian Hickson <ian@hixie.ch> wrote: >> On Sat, 5 Dec 2009, Adam Barth wrote: >>> I think you're missing the main attack that sird's worried about: >>> >>> Assumptions: >>> >>> 1) The attacker can injection content into the target web site, but >>> cannot injection script. >> >> If you grant the assumption that the page has a faulty filter, IMHO >> it >> becomes easy to have all kinds of vulnerabilities. That filters >> should >> make sure the user can't insert arbitrary CSS is not new. Selectors >> and >> expressions get more and more expressive with each year, but they >> pale in >> comparison to the kind of deep analysis you can do to a page using >> XSLT >> and XPath, for example. This is why filters should always whitelist >> only >> features they consider safe. > > The issue is slightly more subtle than you describe. Filters aren't > "faulty" or "safe," they just restrict what kinds of things the > attacker can inject. The question is what bad things the attacker can > do with these injections. sird's point is that allowing CSS is more > severe than it used to be (modulo expression() and -moz-binding, which > are generally considered poor features from a security point of view). It seems like your filter would have to pass through both CSS and seamless iframes to increase the attack surface. - Maciej
Received on Monday, 7 December 2009 10:53:59 UTC