Re: Remove paths from CSP?

On 20-May-14 15:17, Mike West wrote:
>     * 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)

Then we agree, I don't think it is unique either. Sites can create this
hole in other ways too, many already have. Though sites which do not
currently have this hole (previously secure sites), may now get it.

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

Saying "all" is, as you point out, an overstatement, my apologies. What
I meant is that all sites must keep it in mind and watch out for it. The
cross origin loads do not need to be logins though, other types of
redirects can also be vulnerable. E.g. automatically
redirecting me to my most used forum, whether that be, or (Apologies for getting
you all flagged in NSA's database.)

>     * It doesn't fully support the path construct (doesn't work after
>     redirects).
> True. Do you have a suggestion to avoid this limitation?

Not with this solution. The alternative solution of removing error
reporting would avoid this.

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

I thought this change was that the path components will be ignored after
redirects, maybe I don't understand your quote? Either way, we are
already confusing each other ;) CSP is horrendous, this will make it
horrendouser... And we are outsourcing the understanding to third
parties (webmasters), given their numbers, even marginal changes can
have a huge impact.

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

Touche! I am personally not happy with the current protection offered by
Opera though. And the current confusion/false sense of security
regarding Opera is that we are not following the spec. The proposed spec
change will make the complexity part of the spec itself, so I do think
it is worse.

However, I do not think I will be able to convince you to support the
alternative proposal of dropping error reporting instead, even if that
from a security point of view is better. And I don't think you will be
able to convince me that this tradeoff is for the better of the web. If
you have questions or want clarifications, I will be happy to provide
them, but for you and me to discuss the finer points any further does
not seem to bring much benefit. I seem to have failed to garner any
vocal support for my point of view from other members too. I wanted to
state that I am still opposed to this solution, but if this otherwise is
the consensus of the working group, I will not hold it up, and will
instead attempt to give constructive feedback on this solution.

Sigbjørn Vik
Opera Software

Received on Tuesday, 20 May 2014 14:18:47 UTC