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

CSP reports: `script-sample`

From: Mike West <mkwst@google.com>
Date: Mon, 17 Oct 2016 16:15:39 +0200
Message-ID: <CAKXHy=fseKn0inGkryMpvVOJ68uhrYYBkaM_r3C4qD5vys+DSQ@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>
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:16:32 UTC

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