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

Re: Remove paths from CSP?

From: Mike West <mkwst@google.com>
Date: Wed, 12 Feb 2014 12:38:53 +0100
Message-ID: <CAKXHy=d3j6Thpa0b8gTXPbY0XCQnKrPO6-NtRK0=A-f+zmrXjQ@mail.gmail.com>
To: Egor Homakov <homakov@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Feb 12, 2014 at 12:11 PM, Egor Homakov <homakov@gmail.com> wrote:

> Detection is based on a redirect, ( Trusted redirects to NotTrusted, we
> can detect NotTrusted). But since Trusted *redirects* to other location,
> maybe we should mark that new location as Trusted too, not check it against
> whitelist again?
>

That's a reasonable workaround, but not without risk. See below.


> I don't see any downsides of this approach. If you can fake the redirect,
> you can fake the entire response (attacker likely hacked that server
> already).
>

The downside is that some services have open redirects, or clumsily operate
URL shorteners on the same origin as content (https://mkw.st/r/csp, for
instance). I'm sure that somewhere on 'google.com' for instance, you'd be
able to find a script that redirected to whatever you like (I assume
someone somewhere wrote a variant of 'google.com/url?...' that doesn't have
an intersitial step, accidentally or intentionally).

It's not clear to me that the risk of redirects being used to hide
malicious content is lower than the risk of leaking data by blocking
redirected resources.

-mike
Received on Wednesday, 12 February 2014 11:39:50 UTC

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