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

Re: [SRI] reporting (Was: [SRI] require-sri-for syntax and additional SRI/CSP interaction

From: Frederik Braun <fbraun@mozilla.com>
Date: Fri, 9 Sep 2016 12:56:11 +0200
To: Mike West <mkwst@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <cf83e1fb-4d42-ada1-8272-bb3f77af7d8d@mozilla.com>
On 09.09.2016 12:45, Mike West wrote:
> On Fri, Sep 9, 2016 at 12:16 PM, Frederik Braun <fbraun@mozilla.com
> <mailto:fbraun@mozilla.com>> wrote:
>     > What would this reporting entail? I recall us being intentionally wary
>     > of reporting whether or not a cross-origin endpoint returned data that
>     > matched a given hash if that endpoint hadn't also opted-in via CORS
>     > headers. Can I assume that you'd only report "This endpoint didn't
>     > opt-in.", and not the resource's hash, in those scenarios?
>     We can report integrity mismatches, but yes, I am aware that we can not
>     report the hash of the offending resource. What we can report is the
>     desired resource and the expected hash.
>     We should also consider reporting a failed fetch due to the response not
>     being cors-enabled.
> As long as this doesn't give the reporting endpoint any additional
> ability to determine the contents of a SRI'd resource, I'm fine with
> reporting violations. That is, `<script src='https://example.com/js'
> integrity='[correct hash]'></script>` and `<script
> src="https://example.com/js' integrity='[incorrect hash]'></script>`
> should both generate reports if `example.com <http://example.com>`
> doesn't opt-in with CORS headers, and they should probably contain the
> same data.

Indeed. I was assuming that the current implementations bail-out just
after the failed CORS test, not leaving a lot of room to report
sensitive data.

> -mike
Received on Friday, 9 September 2016 10:56:41 UTC

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