On Mon, May 26, 2014 at 8:01 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, May 26, 2014 at 5:13 PM, Mike West <mkwst@google.com> wrote: > > 1. The current candidate recommendation (http://w3c.org/TR/CSP) makes > it > > possible to read the origin of a cross-origin redirect's target (e.g. > > `google.com` to `accounts.google.com`) by examining violation > reports. > > Still following along from the sidelines, are we violating > http://fetch.spec.whatwg.org/#atomic-http-redirect-handling here? Indirectly, yes. Here's one example of how: Assume a `example.com` redirects you to a login page if you hit a protected resource without a cookie. That is `https://example.com/resource` returns a 302 to `https://accounts.example.com/`. You can detect this in a few ways, depending on what kind of resource `https://example.com/resource` is. Assume it's an image. In that case, an attacker can send `img-src example.com`, and put an image tag on her website. If the image loads, it will resize accordingly (or she can read `nativeWidth`, etc). If the image doesn't load because it redirected to the login page, she'll get a violation report, and thereby know that the user isn't logged in to example.com. She'll also be able to read `nativeWidth`, look at the image size, etc, but it will be more difficult to distinguish a legitimate network error from a CSP-based block. -mike
Received on Monday, 26 May 2014 18:08:50 UTC