Re: Remove paths from CSP?

On 24-Feb-14 14:50, Mike West wrote:
>     b) Only consider the first URL, do not block resources based on the
>     redirected-to URLs.
>     Pro: Removes all leakage.
>     Con: Lots of open redirects exist, any such allowed by CSP would render
>     the protection useless.
> 
> Egor's suggestion is a variant of B: only consider the first URL when
> processing source expressions with a path, while continuing to apply
> path-less source expressions to redirects.

Let us call this b-2.

> That is, `script-src https://example.com https://evil.com/thegoodbits/`
> would block `example.com/redirect` <http://example.com/redirect`> ->
> `evil.com/evil` <http://evil.com/evil`>, but allow
> `evil.com/thegoodbits/redirect` <http://evil.com/thegoodbits/redirect`>
> -> `evil.com/evil` <http://evil.com/evil`>. The latter seems an unlikely
> enough risk to be worth accepting.

This seems to combine the worst of the other suggestions. It only
removes part of the leakage (e.g. logged-in detection is still
possible), and it risks losing all of the CSP protection if there are
open redirects allowed. It is confusing for a web author, if trying to
secure his web page by making CSP more strict (enabling paths), he might
accidentally make his web page less secure instead (because of unrelated
open redirects).

>     c) Don't leak cross domain information to the originator. (Remove
>     report-uri, and pretend the resource loaded as normal.)
>     Pro: Removes all leakage.
>     Con: Removes debugging features. The most complex to implement.
> 
> Honestly, I don't believe that C is implementable. There are too many
> side channels.

It is the most complex solution[1], and there will be side channels
(e.g. timing). It will be implementable though, this is known as the
same-origin-policy, and web browsers have a long history of implementing
this, despite the challenges involved. There will be fewer side channels
than b-2 (b-2 has side channels baked in as a feature), none that don't
already exist today (and then no worse), and none that cannot be
protected against if a website so wishes. Even if not implemented
perfectly, it will still be both more secure and easier to understand
than b-2.

If there are any particular side channels you are concerned about, that
are worse than the side channels built into b-2, please mention them, so
they can be considered explicitly.

[1] The most complex solution for those who need to fully understand it.
However, since web authors need to spend less time to understand their
part than for b-2, and there are many more web authors than browser
developers, it will still be less complex for the web at large.

-- 
Sigbjørn Vik
Opera Software

Received on Monday, 24 February 2014 16:20:23 UTC