W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: [Content Security Policy] Proposal to move the debate forward

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Fri, 28 Jan 2011 12:45:48 -0800
Message-ID: <AANLkTinVkTEhYiomcyfFPNYGD_QWb66k643ArPPEm=Ty@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 January 2011 20:46:41 GMT