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

Re: Remove paths from CSP?

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Tue, 25 Feb 2014 10:43:42 -0800
Message-ID: <CALx_OUAVgT+OLzSi518CEp_CwQZ6fy4JvLnZdj66aVHy6wFx3A@mail.gmail.com>
To: Sigbjørn Vik <sigbjorn@opera.com>
Cc: Mike West <mkwst@google.com>, Dan Veditz <dveditz@mozilla.com>, Egor Homakov <homakov@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Michal Zalewski <lcamtuf@google.com>, "Eduardo' Vela" <evn@google.com>
> For services such as gmail and hotmail, the login happens on a different
> domain than the service. This is an extremely common setup, including on
> high value targets, which prior to CSP would be safe. I consider this a
> significant increase in attack surface. Personally, I consider any
> solution which instantly reveals logged-in status on such services to be
> a security flaw, and a non-starter.

This is independent of the CSP path behavior, though: "regular" CSP is
also susceptible to it. I do agree that CSP makes such probing more
convenient. I disagree that it offers a unique opportunity for login
state detection on the modern web: measuring the side effects of image
and script loads works for pretty much every major destination on the
web.

In some cases, the path attacks outlined by Egor would be possible
without CSP, too, although to a much more limited extent. So I worry
about the path behavior a lot more.

I do agree with Mike that preventing sites from being able to measure
if a CSP-governed resource load succeeded or failed to load is nearly
impossible to accomplish without essentially rewriting the browsers
from scratch.

I'm actually mildly happy about the proposed workaround with path
checking on the initial URL and origin checking on redirects. It's
ugly and not necessarily very intuitive, but that makes it blend in
perfectly ;-)

/mz
Received on Tuesday, 25 February 2014 18:44:30 UTC

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