Re: Remove paths from CSP?

On 30-May-14 16:51, Mike West wrote:

> My narrow point here is that any solution to the login detection
> mechanism presented in this example would also prevent CSP from
> detecting the login via the same entry point.

Which is what I am trying to show you is incorrect :) The author was
limited to using image based redirects, because he couldn't use other
redirects reliably. CSP can.

> 1. Replacing a login-requiring redirect with a 403 error page that
> contains a login form with a cross-origin action seems like a perfectly
> reasonable way of dealing with the issue of redirect detection.

That would break every inline that is served via a redirect.

> I'd like to understand how you envision reporting working in a way that
> doesn't expose the hole you're pointing to. This sounds like a useful
> avenue of exploration.

There are many ways of doing that. For this case:
Webmasters want to know if an inline they expected to work was blocked
for some reason. We do not want to leak third party information.
One simple solution is some kind of whitelisting on the cross domain
servers, that they may be reported to the master domain.
Another solution is to create tools for webmasters to easily see which
same domain inlines have been loaded, and which inlines have ended up
requesting cross domain resources.
I have not spent much time on coming up with an alternate reporting
scheme, but there are many possibilities.

>     It doesn't reveal to the page if the content was loaded or not, so no
>     cross domain leakage, which is the current problem with the spec.
> 
> A lot of that claim depends on the details, I suppose. And all of it
> depends on there being no side-channel leakage, which is unlikely to be
> the case.

What new forms of side channel leakage do you foresee?

> CSP mitigates these risks, it does not prevent them. I hope I didn't
> claim that it did, only that blocking requests is more effective than not.

Very marginally, about as much as a fence with a big gap in it is a
security improvement over no fence. ;) I do not see data exfiltration
protection as an argument for CSP.

> * She's significantly better off for having constructed a policy:
> `evil.com <http://evil.com>` still won't load, which is great! The
> potential impact is limited to scripts that share an origin she's
> whitelisted, which isn't nothing.

Agreed, the time she has taken to implement CSP might be well worth it.
My point is about the time she has taken to implement path restrictions,
it might have been a complete waste.

> * If the developer doesn't expect to load redirected resources, perhaps
> we could add an 'unsafe-redirect' (or similar) source expression which
> she'd have to add to her policy in order to allow any redirection in the
> first place. That would further mitigate the risk posed by accidental
> introduction of otherwise whitelisted redirects.

CSP protects the origin, not the target. This will not help against
redirection detection on the target. (Why would an attacker limit
himself by using unsafe-redirect?)

> Spear phishing again. And short of buying everyone on the internet
> Invincea firewalls, I'm not sure what CSP can do to help attackers.

My point was simply to show that phishing is considered a much worse
threat than XSS on the net. Spear phishing might be the biggest part of
this, but phishing is still how most people get exploited, not XSS. I am
open to changing my mind if you can find statistics showing me otherwise.

> Alright, this is totally valid. I'm much less worried about this than
> about spear phishing, however, as I'd claim that untargeted spam is the
> type of phishing attack most likely to be shut down by SafeBrowsing and
> similar services. They totally aren't perfect, but _this_ type of
> phishing is what they're good at.

A malicious ad on a website will not be blocked by SafeBrowsing until it
has been up for some time, opening up for users to be exploited in the
meanwhile. And I do not believe us opening up a new security hole on the
internet is ok just because services like SafeBrowsing most likely will
be able to deal with it after some time.

-- 
Sigbjørn Vik
Opera Software

Received on Monday, 2 June 2014 08:04:11 UTC