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

Re: Remove paths from CSP?

From: Sigbjørn Vik <sigbjorn@opera.com>
Date: Wed, 26 Feb 2014 11:14:33 +0100
Message-ID: <530DBE89.6000803@opera.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
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>
On 25-Feb-14 19:43, Michal Zalewski wrote:
>> Personally, I consider any
>> solution which instantly reveals logged-in status on such services
>> to be a security flaw, and a non-starter.
>
> 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.

I don't think anyone has claimed this is a unique opportunity.

Let me repeat myself: That an exploit works against many sites, is not a
valid argument to build that security hole into browsers by default.
Protecting against side channels from image and script loads is trivial
for web sites which care. There might not be many of them (today), but
removing the possibility to protect websites is not good security practice.

> 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 don't think anyone has suggested we do this though.

My suggestion is that browsers pretend the resource loaded. E.g. CORS
and XHR have lots of behaviour just like this, where the real state of
the load attempt is never revealed to the document. Copying such
features across to CSP hardly seems impossible.

I have still to see a single argument of something which would be hard
to implement in such a solution, all I have seen is generic fear and
uncertainty.

-- 
Sigbjørn Vik
Opera Software
Received on Wednesday, 26 February 2014 10:15:07 UTC

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