Intent to Deprecate and Remove: Sniffing 'audio/*', 'video/*', and 'text/csv' into script.

[Mike West]

eng (and PM) emails

mk...@chromium.org

Summary

Currently, `<script src="whatever"></script>` will execute the resource at `whatever` as long as it returns a non-`image/*` MIME-type (and doesn't opt-in to additional protection by sending an `X-Content-Type-Options: nosniff` header). I'd like to tighten this to exclude `text/csv` as well as `audio/*` and `video/*` by default.

Motivation

Executing `text/csv` resources as script is actually problematic, as CSV is sufficiently JavaScript-like to allow reading data cross-origin (see https://bugzilla.mozilla.org/show_bug.cgi?id=1048535). The latter two are opportunistic baby-steps towards sanity in sniffing that it looks like we can safely make.

Compatibility Risk

It's possible that some folks are (inadvertently?) serving real scripts with a `text/csv`, `audio/*` or `video/*` MIME type. Firefox recently added metrics for this, and their data shows basically zero usage: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2016-08-24&keys=__none__!__none__!__none__&max_channel_version=nightly%252F51&measure=SCRIPT_BLOCK_WRONG_MIME&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-08-22&table=1&trim=1&use_submission_date=0. We'd want to keep an eye on that as this rolls through our release channels.

According to https://github.com/whatwg/fetch/pull/379, Mozilla is interested in shipping this change.

Alternative implementation suggestion for web developers

Serve JavaScript with a MIME type of `application/javascript` so that we don't have to sniff?

Usage information from UseCounter

See Firefox's data above. We don't yet have a counter.

OWP launch tracking bug

https://crbug.com/433049

Entry on the feature dashboard

https://www.chromestatus.com/feature/6031053726679040

Requesting approval to remove too?

Yes

[Jochen Eisinger]

lgtm1

[Jochen Eisinger]

is it also possible to not execute text/html as script?

[Mike West]

On Wed, Aug 31, 2016 at 11:56 AM, Jochen Eisinger <joc...@chromium.org> wrote:

is it also possible to not execute text/html as script?

Possible, yes! Maybe even practical. `text/html` isn't in Mozilla's data set at the moment. `text/xml` is, and has minimal usage. `text/plain` is high (~1%). I'd imagine `text/html` is somewhere between those two.

I'd suggest that we add a counter to Blink at the same time we land this to see if we can tighten things even further. I don't think we need to lock everything down at once, but the eventual goal should be to act as though a `nosniff` assertion was made for both script and style.

-mike

[Mike West]

I should have noted that we do have data here, it's just not granular enough. That is, we know that:

* ~91.5% of page views either don't load scripts, or load scripts with expected MIME types.

* ~1.97% of page views load scripts with an unexpected `application/*` type

* ~3.17% of page views load scripts with an unexpected `text/*` type

* ~3.34% of page views load scripts with some other (or no specified) type

These are culled from the `{Cross,Same}Origin{Application,Other,Text}Script` counters.

Those numbers worry me, you see. So I'd like to be a little careful about breaking the internet by breaking that big number down into smaller buckets whose risk we can more easily weigh. :)

-mike

[Philip Jägenstedt]

LGTM2

It looks like https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-mime-type? is the spec for this. Is there a chance that we could end up with a whitelist, is that what "Mozilla's data set" is?

[Mike West]

On Wed, Aug 31, 2016 at 12:27 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

LGTM2

It looks like https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-mime-type? is the spec for this. Is there a chance that we could end up with a whitelist, is that what "Mozilla's data set" is?

That's what I hope, yes.

-mike

[Chris Harrelson]

LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Simon Pieters]

I tried checking for MIME types in httparchive. I couldn't find an easy
way to isolate <script src> fetches but checked Accept: */* request header
instead, as I believe that is used for <script src> and some other things
but not all things (does somebody know which fetches use Accept: */* in
Chrome?).

See
https://discuss.httparchive.org/t/which-mime-types-are-used-for-accept-requests/821
for the query

and https://gist.github.com/zcorpan/cb42a1037b4ee15494983fba1ecfd5a8 for
the result

--
Simon Pieters
Opera Software

[Mike West]

On Thu, Sep 1, 2016 at 12:28 PM, Simon Pieters <sim...@opera.com> wrote:

I should have noted that we do have data here, it's just not granular
enough. That is, we know that:

* ~91.5% of page views either don't load scripts, or load scripts with
expected MIME types.
* ~1.97% of page views load scripts with an unexpected `application/*` type
* ~3.17% of page views load scripts with an unexpected `text/*` type
* ~3.34% of page views load scripts with some other (or no specified) type

These are culled from the
`{Cross,Same}Origin{Application,Other,Text}Script` counters.

Those numbers worry me, you see. So I'd like to be a little careful about
breaking the internet by breaking that big number down into smaller buckets
whose risk we can more easily weigh. :)

I tried checking for MIME types in httparchive.

Thank you for digging into this!

 

I couldn't find an easy way to isolate <script src> fetches but checked Accept: */* request header instead, as I believe that is used for <script src> and some other things but not all things (does somebody know which fetches use Accept: */* in Chrome?).

Lots of things, unfortunately: https://cs.chromium.org/chromium/src/content/browser/loader/mime_type_resource_handler.cc?rcl=1472642334&l=158. `*/*` is the default for everything that isn't an image, stylesheet, or frame.

-mike