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

Re: Remove paths from CSP?

From: Mike West <mkwst@google.com>
Date: Tue, 3 Jun 2014 10:52:19 +0200
Message-ID: <CAKXHy=cOne+vFLfCL5kpw2Npv=CFkAHy6b3mAZduYTFjEjMQTg@mail.gmail.com>
To: Sigbjørn Vik <sigbjorn@opera.com>
Cc: 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, Jun 2, 2014 at 4:33 PM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> So summing up (or we can keep going forever :)

You do a _much_ better job summarizing than I do.

> We agree that CSP opens up some new possibilities for redirection
> detection. Using 403's to protect against this will work in some cases.
> Reporting may possibly be solved in other ways.

Would you like to put together a more concrete proposal here? I'm
interested in more detail around what you think we can safely report, and
how we might go about doing it.

I'll put together some sort of sampling proposal for the current spec,
something along the lines of "User agents MAY choose to send only a subset
of reports, [insert explanation here]."

Developers accidentally shooting themselves in the foot may largely be
> solved by disallowing redirects by default.

I'll flesh out the 'unsafe-redirect' proposal; I think it's probably
valuable and might reduce confusion.

> We disagree about the relative threat scenario, but neither has hard data.
> >     What new forms of side channel leakage do you foresee?
> >
> > Nothing new, just the same old wonderfulness. [...]
> If there are no new attacks, I don't see that as an argument against
> blanking out disallowed loads, and proceeding as normal.

Sorry, I was unclear. I don't think there are new _forms_ of side channel
leakage. I do suspect, however, that replacing a document with a blank
document (or image with a blank image, etc) will be detectable via the
existing forms of side channel leakage (e.g. filters on an image).

> Data exfiltration protection does not seem like a strong argument
> against this either, at least not in its current (weak) form.

Not an overriding argument, no, but one that I'm reluctant to throw away

Received on Tuesday, 3 June 2014 08:53:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:38 UTC