Re: Remove paths from CSP?

It was a good idea to consider <meta> redirects too. Furthermore, I propose
to allow all kinds of navigation after the page is loaded.

This kind of detection is possible now:
Allow in CSP frame-src = http://social-network/home and
http://social-network/homakov
/home page renders the following HTML: <a href="/homakov">Your profile</a>

Now if we trick user into clicking Your Profile (using regular clickjacking
techniques) we can learn what was the URL in Your Profile link. It requires
no-XFO header though, but on the other hand it will work on almost every
website with social profiles and w/o XFO. Each website has a direct link to
your profile, and 302 redirect ( /profile->/johndoe ) is not even required
here.

Does it sound like a threat?




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

> 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.
> > google.com <http://google.com> -> accounts.google.com
> > <http://accounts.google.com>).
>
> 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. forum.org automatically
> redirecting me to my most used forum, whether that be gay.forum.org,
> breast-cancer.forum.org or al-quaeda.forum.org. (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
>