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

Re: Remove paths from CSP?

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 27 May 2014 09:53:57 +0200
Message-ID: <CADnb78gikvcFy2Ky8qFr59tRnNLRd6kKtMZmg-KoCr1614PUAA@mail.gmail.com>
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

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