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