Re: Remove paths from CSP?

On Tue, May 20, 2014 at 2:55 PM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> For the sake of playing the devil's advocate, why limit ourselves to
>
HTTP redirects? Certainly meta http-equiv redirects should be treated
> the same way. What about various JS redirects? Both the algorithm and
> the discussion should probably use the same language, to make it
> explicitly clear what is being considered. (Currently algorithm says
> "HTTP redirect" and discussion says "redirect".)
>

Meta redirects wouldn't effect subresource loads. They'd only effect full
navigations that created a document context in which the <meta> tag was
parsed and executed. That wouldn't happen for the vast majority of things
that CSP covers (images, for instance). `frame-src` is the only directive I
can think of where <meta>-based refreshes would have an impact, and I think
they'd be covered by the navigation bits in the `frame-src` directive.

We've talked about adding a directive to control things like meta-based
redirects, but there's a bit more to think about in terms of what we'd like
to offer to authors with regard to control over navigation in general. It's
not something I think we can squeeze into 1.1, but we'd like to circle back
to it for 1.2.

For the record, I am still opposed to this solution. I'll quickly recap
> my objections against it:
>

This is helpful, thank you for reiterating your critique so concisely!


> * It doesn't resolve redirection login detection, which may add a new
> security hole to previously secure sites, one against which sites cannot
> protect themselves.
>

I disagree that this is a unique consequence of CSP's behavior (as we've
discussed at length), but I do agree that CSP makes this detection for
those sites that do cross-origin easier than it is now.

* It thus adds an unfixable security issue for the foreseeable future
> for all web sites. This might theoretically hinder the web moving
> forwards in the future.
>

For the subset of all websites that do cross-origin login (e.g. google.com->
accounts.google.com).


> * It doesn't fully support the path construct (doesn't work after
> redirects).
>

True. Do you have a suggestion to avoid this limitation?


> * It is confusing and complex for webmasters (and as they vastly
> outnumber browser developers, it is the most confusing and complex
> solution overall).
>

Is it? The rule sounds simple: "The path component of a source expression
always matches after a redirect." I agree with you that it adds some
marginal complexity to CSP, but let's not kid ourselves: CSP is already
horrendous.


> * It provides a false sense of security to webmasters. A webmaster might
> accidentally open a hole when trying to tighten security, or an
> unrelated change elsewhere (e.g. changes to use a redirect) might render
> a site insecure.
>

At worst, the protection offered to developers and users is exactly the CSP
1.0, origin-based protection that Opera is providing right now. I think
that's a pretty good baseline, honestly.

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