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

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

From: Mike West <mkwst@google.com>
Date: Fri, 9 Sep 2016 11:50:14 +0200
Message-ID: <CAKXHy=fKp+fBP3d5f4YYm1z2nTh-Wsn8pP6CFHkdD89+gWiYNQ@mail.gmail.com>
To: Frederik Braun <fbraun@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Fri, Sep 9, 2016 at 9:28 AM, Frederik Braun <fbraun@mozilla.com> wrote:

> Hi,
> (This e-mail is assuming you are familiar with require-sri-for in the
> latest editor's draft at
> <https://w3c.github.io/webappsec-subresource-integrity/#parse-require-sri-
> for>.)
> People have asked for SRI reporting, SRI report-only. I suggest we bake
> all SRI/CSP interaction into a single CSP directive.

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?

> Thus, I am suggesting we rename the require-sri-for directive into e.g.,
> "sri-options". For now, the directive would understand the tokens
> 'require-script' and 'require-style' [1]

Are there any other options you're interested in adding? That is, it's not
clear to me that you need 'sri-options' if 'require' is the only thing
you're optioning. Given the current `require-sri-for`, you can simply start
sending reports if `sri` isn't present, using the existing policy's
`report-uri` with a `violated-directive` of `require-sri-for`.

That latter bit of granularity is actually a good reason to split things
up: getting two reports whose violated-directives are both `sri-options`
wouldn't be very helpful if two distinct options were violated.

> CSP tokens in -src: directives that aren't URLs are quoted.
> Referrer-Policy is debating whether things should be quoted or not.
> I'd personally find it less confusing to have everything in quotes that
> is not a URL. Not all directives seem to follow this approach though
> (sandbox, reflected-xss, referrer).

For CSP, we've traditionally wrapped things in single-quotes that aren't
URLs, iff the directive also accepts URLs. We should probably keep doing
that, even though we'd probably do things differently if we were inventing
CSP's syntax today.

Note that for Referrer Policy, the question is not really "should things be
quoted", but "should the syntax be forward compatible with a future in
which something like JSON is the way we write headers". Also note that that
future would require double-quotes, because JSON doesn't do single-quotes.

Received on Friday, 9 September 2016 09:51:05 UTC

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