Re: lcamtuf on the subtle/deadly problem with CSP

On 8/31/11 12:51 PM, Michal Zalewski wrote:
> Obviously the "deadly" part is not to be taken literally: I do not
> think there will be casualties ;-) But I do think that origin scoping
> makes it difficult to meaningfully use CSP with any large and diverse
> web property. I would be surprised if it would not be exploitable in
> places such as facebook.com, msn.com, google.com, twitter.com,
> wellsfargo.com, att.com, etc. I don't have a proof and may be wrong,
> but looks like this is not an isolated sentiment.

By "exploitable" you mean "it might be possible to work around the
CSP restrictions on a case-by-case basis and continue exploiting
some of the sites that are already exploitable without CSP
protection," right?

CSP isn't adding any exploits. Like condoms it may not provide 100%
protection against infection.

> If you guys wish to go with path scoping, though, there's an
> interesting thought experiment, though: why not save some bytes, and
> decouple script loads from the HTML document body completely, rather
> than duplicating the URLs in the policy and then in the document?
> 
> The objection to this proposal is that it decouples some critical
> information from the returned payload, but then, it's not like HTTP
> specs & browser implementations paid too much attention to this before
> (correctly preserving origin, Content-Type, and charset for locally
> saved documents, for example, is a bit of an unsolved problem).
> 
> Let's see how that troll goes over...

I'll butt that troll...

a) doing so defines an incompatible not-HTML. Only CSP-supporting
browsers would run those pages at all. Chicken-and-egg, never going
to happen.

b) for most simple sites specifying CSP is simple. Your proposal
forces CSP to become more complex--complexity is already one of your
complaints!--and therefore unlikely to be adopted.

c) you don't need to specify full files to get a benefit from path
scoping. The path on http://mysite.com/widgets/ isn't adding enough
bytes to be worth saving. Of course a complex site will benefit from
a much more complex policy. Each site can make the trade-off of
simplicity vs. protection for themselves. Your thought experiment
removes that flexibility, it's all or nothing.

d) you claimed it would be more efficient (I snipped that bit), but
it forces each page to have a separate custom policy that fully
specifies each and every script. Because of the added complexity the
policy is certainly not going to be in the header and will require
an external file. The current more general CSP allows for the
possibility that the same policy file--if an external policy is even
used!--will work for large sections of a site and can be cached.
Your proposal loses on efficiency.

e) scripts from ad-servers are going to be a problem in your
proposal. First it means the page author needs to know the
ever-changing structure of their ad partners. Second, many of those
scripts expect to be loaded synchronously and document.write() the
ad content at a specific point in the file. Not a practice I like,
but it's not going to go away just because I have a shiny CSP to
wave in people's faces. Maybe we could come up with a specification
on where to insert but that's even more complexity.
  [here's an attempt: resources in the policy are numbered
  and the document gets sprinkled with special urls like
  <script src="csp://3">]

f) there's no longer any separation between the document definition
and the security policy. If you make a mistake in one the other
isn't there as a back-stop to catch you. CSP would effectively be
reduced to the ban on inline-scripts and eval, and if that's all we
get out of it we can do that in simpler ways. Spitballing here, but
maybe a header like "CSP: yes-please"

g) the thought experiment means the policy MUST be generated by the
page authors because they are so intimately tied. I agree it's
likely to be the case most of the time with CSP, but the current CSP
specification does allow an IT security team to impose an overall
policy by injecting a header on outbound responses.

h) tying the policy to the functionality will make the policies
"noisy" and harder to audit. There will be far more of them to audit
(a custom one per page) making it infeasible to check them all.

Is that enough to knock this troll back under the bridge?

-Dan Veditz

Received on Thursday, 1 September 2011 02:08:09 UTC