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

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