- From: Mike West <mkwst@google.com>
- Date: Wed, 12 Feb 2014 12:38:53 +0100
- To: Egor Homakov <homakov@gmail.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Received on Wednesday, 12 February 2014 11:39:50 UTC
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