W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2016

Re: CSP reports: `script-sample`

From: Mike West <mkwst@google.com>
Date: Mon, 17 Oct 2016 16:37:38 +0200
Message-ID: <CAKXHy=fn-iZhpXo0_9N2zVpLPE-dvmEuPqw=XOfaEDdsLtV24w@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Cc: Artur Janc <aaj@google.com>, Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, Frederik Braun <fbraun@mozilla.com>, Scott Helme <scotthelme@hotmail.com>, Lukas Weichselbaum <lwe@google.com>, Michele Spagnuolo <mikispag@google.com>, Jochen Eisinger <eisinger@google.com>
+Lukas, Miki, and Jochen, who I intended to add but didn't.

-mike

On Mon, Oct 17, 2016 at 4:15 PM, Mike West <mkwst@google.com> wrote:

> Hello, webappsec!
>
> Last week, Artur, Christoph, Freddy, and I had a conversation about
> reporting more detail for script-based violations. In particular, Artur and
> his team at Google would love for Firefox's `script-sample` report field to
> be implemented in Chrome (and extended in Firefox) to help them diagnose
> inline event handlers, scripts, etc. The conversation was a bit
> contentious, so bringing it to the list might be interesting, as I expect
> folks to have opinions. I have a few myself.
>
> I think there was general agreement on two points:
>
> 1. It's totally reasonable to provide developers with more information
> about violations on their own pages. They can already crawl the DOM via
> JavaScript, so the data contained in `<script>` and inline `onX` handlers
> is something they could potentially hack their way to reporting via
> 'SecurityPolicyViolation' events (by reporting everything on the page, if
> nothing else).
>
> 2. It's not reasonable to provide developers with details of third-party
> script, unless that external script has opted into sharing details via
> CORS. Though Firefox correctly sanitizes script errors per spec, it doesn't
> appear to sanitize `script-sample`; that continues to worry me.
>
> There was less agreement on this third point:
>
> 3. I'm worried about sending the contents of inline script blocks to a
> third-party, as those blocks seem to me to be the most likely to contain
> sensitive information (`var email = 'mike@mikewest.org';`, `var ssn =
> '123-45-6789';`, etc). I'm worried about this for two reasons: a) it might
> enable abuse, especially in the context of embedded enforcement, and b)
> reports seem by their nature to be delivered to logging servers which
> probably don't have the same kinds of data retention policies (or
> understanding of data sensitivity) as other systems.
>
> Artur, and others, suggested that this isn't much of a concern because a)
> the data is already available to script, and b) any sensitivity is
> mitigated by manipulating the data somehow (stripping to ~40 characters
> like Firefox does, stripping constants, etc.).
>
> With those in mind, I'm thinking:
>
> 1. Firefox should reexamine it's behavior for cross-origin script (perhaps
> it already has?).
>
> 2. Inline event handlers are probably fine to report; they're unlikely to
> contain sensitive data, are already available to JavaScript that crawls the
> DOM, etc.
>
> 3. Inline scripts worry me, but maybe they shouldn't worry me as much as
> they do. It's not clear to me what kind of metric we could use to make a
> real decision here, but anecdata from Google's deployment shows that the
> `script-sample` data gathered from Firefox hasn't been sensitive. It's
> unclear how well that applies to the rest of the web (or, indeed, to
> Google's sites that aren't yet using CSP). Perhaps Mozilla folks did some
> research when implementing this feature that justify/explain the 40
> character limit as sufficiently-safe?
>
> What do y'all think?
>
> -mike
>
Received on Monday, 17 October 2016 14:38:31 UTC

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