- From: Mike West <mkwst@google.com>
- Date: Mon, 17 Oct 2016 16:37:38 +0200
- 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>
- Message-ID: <CAKXHy=fn-iZhpXo0_9N2zVpLPE-dvmEuPqw=XOfaEDdsLtV24w@mail.gmail.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