W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2014

Re: Remove paths from CSP?

From: Sigbjørn Vik <sigbjorn@opera.com>
Date: Tue, 27 May 2014 11:31:08 +0200
Message-ID: <53845B5C.8030909@opera.com>
To: Mike West <mkwst@google.com>
CC: Daniel Veditz <dveditz@mozilla.com>, Joel Weinberger <jww@chromium.org>, "Oda, Terri" <terri.oda@intel.com>, Michal Zalewski <lcamtuf@coredump.cx>, Egor Homakov <homakov@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Eduardo' Vela <evn@google.com>
On 26-May-14 17:13, Mike West wrote:

> it allows attackers a
> perfect oracle for the logged-in status of users on those websites that
> redirect
> directly to a cross-origin login page in response to a resource request
> (or have
> a "are you logged in?" endpoint that redirects to a resource (as Google
> shouldn't but does[3])).

CSP allows more than just login detection, and makes login detection
even easier. Existing issues on sites are due to the policies of the web
sites, they do not consider this sufficiently important to protect
against. However, it is up to the sites to make this decision, and they
can protect themselves as they want.

>From (the explanation of) your link: "It seems LinkedIn and Tumblr are
currently immune to this" So the author put in a lot of effort trying to
detect login status of these sites, and failed. With CSP it would work
with minimal effort, and the sites couldn't protect against it, even if
they wanted to.

> large sites anecdotally _always_ have such holes that are
> detectable in CSP's absence.

I do not agree, and neither does your own support material in link
[3]... Many do, but not all, and it is fixable if the site wants.

> Even without the very
> difficult-to-solve problem of timing attacks, basic image requests still
> leak
> quite a bit of data (error events, `nativeHeight`, etc) about cross-origin
> requests, and removing those leakages doesn't seem to be web-compatible.

Removing these issues in a spec might not be web-compatible. Removing
them for a site owner is doable. Removing the hole introduced by CSP is
not doable for a site owner, even if wishing to do so.

> 2.  Reporting provides herd immunity; even in a world where extensions are
>     accidentally blocked by bad browser implementations (I know Blink
>     has some bugs),

I don't follow this.

>     authors use reporting as an ongoing monitor of breaches and
>     potential
>     injection vulnerabilities. At scale, CSP reports can point to the
>     areas of
>     an application that are vulnerable, and point to structural issues you'd
>     never otherwise detect. Twitter used CSP reports as impetus to convince
>     themselves to move to HTTPS to avoid carrier-based injection, if I'm
>     recalling correctly.

Reporting is good, agreed. If reporting is what we are after, there are
other ways to do this, CSP is not a spec designed to provide webmasters
with optimal reporting tools, and is not the only solution to reporting.
Reporting can be done better and more secure in other ways.

If we are serious about reporting, let us make a much better tool for
that, without the security issues, and which can be used not only to
determine the viability of CSP, but other site issues as well. Random
example; I would love to see a spec for a page to determine the security
level a browser awards it - CSP reporting can't do this, and it would be
silly to have one reporting tool for CSP and another for this.

> To address this issue, Sigbjorn suggested that we pretend to the DOM
> that the
> page loaded as it would have without CSP. First, calling this "not
> trivial to
> implement" is a massive understatement. :)

In the network layer, if the page is blocked by CSP, replace it with
blank contents, and continue as normal. No DOM changes necessary.
Calling it "not trivial" might have been an exaggeration. :)

> Second, it removes CSP's
> ability to
> prevent data exfiltration (as we'd have to load the resources to grab image
> dimensions and so on). I think I must be misrepresenting this suggestion,
> because it seems unworkably hard to me.

I don't understand what ability CSP has to prevent data exfiltration,
could you please explain? I tried analyzing this in an earlier mail[1],
but got no responses, so I still don't see any anti-CSRF powers in CSP.
Or did you have something else in mind? Remember that it is the origin
which is protected by CSP, not the target.

> For criticism #2: the question of complexity is, I believe, marginal. If a
> developer can understand CSP well enough to implement it, she can grasp both
> the impact of an impetus for the redirect exception.

Let me quote you ;)
"More to the point, please assume that I and everyone like me is a
terrible programmer. :)"
I do not believe most web developers are going to read the CSP spec, far
less understand it. I believe most will find a working template on
stackoverflow, and copy it in uncritically.

> The suggestion that the
> sheer number of developer means that any increase in complexity needs
> to be carefully weighed is absolutely correct though, so what's the
> risk?

Important question, see summary.

> At worst, we end up in a world where path restrictions don't exist for
> developers who inadvertently allow redirects into otherwise whitelisted
> paths.
> They still have origin-based protections of CSP 1.0. I see that as a
> reasonable
> baseline, though I would certainly appreciate any suggestions that didn't
> involve that compromise.

I think this is much closer to the best case scenario. Developers may
apply CSP, believe they have secured their sites, and leave it at that.
They don't know that open redirects stop path restrictions from working,
nor that another part of the site has an open redirect. Since they left
the security of the site with CSP, and it doesn't work, they are now
worse off than without CSP. So the worst case scenario is that sites get
even less secure then before.


To weigh the risks, it is important to understand the threats.
Currently, phishing is by far the largest threat on the net, XSS is
miles behind. If phishing is critical severity, then XSS is only high
severity. The more a phisher can know about a user, the more convincing
phishes can be made, and redirection detection will give phishers more
power.

So the way I see it, CSP exacerbates the worst threat on the internet,
and leaves no recourse possible. On the good side, it allows
knowledgeable webmasters (a small percentage of all webmasters) yet
another way to protect themselves against a non-critical security risk.
However, if attempted by non-knowledgeable webmasters, they risk making
their site less secure.

My conclusion is that this CSP solution will make the net less secure,
but that CSP can be modified to achieve the opposite.

> [3]: http://www.tomanthony.co.uk/tools/detect-social-network-logins/
[1] http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0077.html



-- 
Sigbjørn Vik
Opera Software
Received on Tuesday, 27 May 2014 09:31:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC