- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 27 May 2014 09:53:57 +0200
- To: Mike West <mkwst@google.com>
- Cc: Sigbjørn Vik <sigbjorn@opera.com>, Daniel Veditz <dveditz@mozilla.com>, Joel Weinberger <jww@chromium.org>, "Oda, Terri" <terri.oda@intel.com>, Michal Zalewski <lcamtuf@coredump.cx>, Egor Homakov <homakov@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "Eduardo' Vela" <evn@google.com>
On Mon, May 26, 2014 at 8:08 PM, Mike West <mkwst@google.com> wrote: > On Mon, May 26, 2014 at 8:01 PM, Anne van Kesteren <annevk@annevk.nl> wrote: >> 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. What if accounts.example.com was a redirect as well? Would we follow that? This seems like another case where example.com wants to protect its resources using the fictional From-Origin header: http://www.w3.org/TR/from-origin/ -- http://annevankesteren.nl/
Received on Tuesday, 27 May 2014 07:54:27 UTC