- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Fri, 28 Jan 2011 12:45:48 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-web-security@w3.org
>> Allowing arbitrary font loads allows various attacks that depend on >> misinforming the user about what buttons and such will do, for example. > In this threat model, they can already do both those things without > the ability to load fonts. They just make an opaque DIV that covers > the whole page and write whatever they like into it. I think the concern here is not with XSS, in that case, yeah, it's game over in terms of site content, even without scripting or fonts. It's more about a well-behaved page that loads subresources from untrusted domains; that sort of "content security policy enforcement" is a good part of CSP (as the name implies ;-). I wonder what's the key disagreement here: 1) That this is not a worthwhile pursuit at all? I think we previously brought up real-world organizational constraints as an argument for <meta> versus HTTP headers, or DOM versus HTTP policy callbacks; and I'm pretty sure that there is a large proportion of organizations where security teams would very much like to monitor for or prevent this type of a (common) mistake, so I'm guessing this is not the problem. 2) That it's worthwhile, just not in the browser? Server-side auditing is a viable alternative, although the browser is definitely the most reliable, all-inclusive, and ultimately simplest location for this sort of logic. 3) That it should be a separate browser-side mechanism? That's probably a valid stance (and it really boils down to philosophical views), but from a pragmatic standpoint, the complexity of having several simple but separate policing mechanisms is almost always higher than having a single reasonably structured one - and in this case, content policing is a fairly natural extension of script load policing. /mz
Received on Friday, 28 January 2011 20:46:41 UTC