Re: Remove paths from CSP?

Thanks Sigbjørn.

Just for clarity up top, I understand your concrete suggestions to be:

1. Remove reporting.
2. Block resources in such a way as to make the page believe that the load
was successful (for example, by populating 'naturalWidth'/'naturalHeight'
for blocked images).

Is that accurate? Or are there other approaches you'd like to see CSP take?

On Wed, Feb 12, 2014 at 2:51 PM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> Origin basis is already bad enough.
>

It's a bad side-effect, I agree.


> > How do we know the original image dimensions if we block the load?
>
> Don't block the load, only the page interaction.
>

I think "page interaction" is going to be difficult to define in a way that
has the effect you want.

* let's say http://service.com/sekritimage.jpg redirects to
http://service.com/login if you're not logged in. Loading that via an <img>
element will reveal whether you're logged in or not, as the former URL is
an image, and the latter isn't. It will do so regardless of CSP, for that
matter. This is not uncommon.

* style's "interaction" with the page are trivially detectable by querying
the CSSOM to get element style details.

* script's "interaction" with the page changes the environment in ways that
are generally detectable (globals, event handlers, effects on DOM, etc).

You agree at the bottom of the email that some effects will be detectable,
but claim that detection will be heuristics-based and flaky. I think you're
underestimating sites' ability to query their own state.

The issue here is that you are solving a problem for the many sloppy
>  developers, by creating a problem for the good ones, thus preventing
> great security (including in the future), even if possibly improving on
> the current average security.
>

This, I suppose, is where we disagree most clearly on the tradeoffs we're
discussing.

I don't believe it's possible for developers, good or otherwise, to do a
perfect job when building websites. Despite solid understanding of XSS and
other injection attacks, and frameworks that take the thought out of
escaping, even the most trivial reflected XSS attacks are _still_
consistently a problem, even for otherwise excellent developers, on teams
with excellent security review practices. It's unfortunately quite easy to
miss things in ways that lead to catastrophic failure.

Additionally, I think you're incorrect to claim that anything we're
discussing here "prevent[s] great security". The worst-case scenario we're
discussing is reading redirection target paths cross-origin. The bad-case
scenario we're discussing is reading redirection target origins
cross-origin. I agree that these are bad things. We should fix them. That
said, even if we end up with both of these, fully exploitable, forever, I'd
still claim mitigation of XSS to be more important. :)

Have I missed other attack scenarios you're concerned with, or do those two
cover things?

> Pretending is difficult, particularly given that we, in the best case,
> > want to avoid making requests for blocked resources.
>
> This is a new problem description. I agree that this would be ideal, but
> the importance of it far less than the original goal, and in my opinion,
> far less than the problems it introduces.
>

New to this thread, yes. Not new to the spec.


> What it does reveal will in most cases be
> indistinguishable from other, unrelated failures, and will at best be
> heuristics based. While not perfect, it is far better than the alternative.
>

As noted above, I disagree with your characterization of this sort of state
being flaky enough to make detection non-trivial.

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)