Open Bug 1333995 Opened 7 years ago Updated 2 years ago

Return a network error for requests whose type is "script" with additional bad MIME types (round 2)

Categories

(Core :: DOM: Security, defect, P3)

defect

Tracking

()

People

(Reporter: dveditz, Unassigned)

References

Details

(Keywords: dev-doc-needed, sec-want, site-compat, Whiteboard: [domsecurity-backlog1])

+++ This bug was initially created as a clone of Bug #1299267 +++

Now that improved telemetry (and some blocking) has made it to Firefox 51 it looks like we're clear to follow the "must not" in the HTML spec[1] and block additional types:
  text/xml          0%
  application/xml   0.01%

Without careful investigation it would be dangerous to block
  text/plain (0.71%, a billion loads).

We might be able to block
  application/octet-stream (0.08%, 144 million loads).

Telemetry (beta 51):
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-01-18&keys=__none__!__none__!__none__&max_channel_version=beta%252F51&measure=SCRIPT_BLOCK_INCORRECT_MIME&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-11-15&table=0&trim=1&use_submission_date=0

[1] https://www.w3.org/TR/html5/scripting-1.html#scriptingLanguages
1) We should use https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages.
2) That list and the requirements around it are meanly meant for <script type>. They are not meant to apply to network fetches. I filed https://github.com/whatwg/html/issues/2301 to clarify that.
3) Nevertheless, blocking more MIME types and adding those to https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-mime-type? seems reasonable.
I'm not following your comment. We cannot blindly implement the spec without knowing what we will break. We implemented telemetry to know what will break. Right now we're working on the second list at your reference "must not be interpreted as scripting languages:" and telemetry seems to say we can forbid the xml ones but probably not text/plain.

Maybe later we can get to the "only allow these explict script types" state, but that's not where we are.
Flags: needinfo?(annevk)
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]
I'm saying that the HTML Standard does not say what you think it says. It does not require that the response of a <script src> fetch has a correct MIME type. The list of MIME types listed there is used for <script type> and Fetch uses it for "nosniff". (Very deliberately, we don't want to require things that can't be shipped.)

The next point I made was that figuring out if we could block more MIME types and add those to Fetch (https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-mime-type? in particular) as we go seems worthwhile, provided other browsers do the same (and block them in the same way, we've had some fallout because Chrome doesn't do the same kind of checks for importScripts() and such).
Flags: needinfo?(annevk)
Depends on: 1510223
Depends on: 1510241
Depends on: 1514680
New data since bug 1510225 landed: https://mzl.la/2GxHc9Q. "application/json" is huge probably JSONP endpoints.
Depends on: 1523706

I wonder if we could allow only the JavaScript MIME types plus the top incorrect MIME types (text/html, application/json, text/plain, empty) and disallow everything else.

Depends on: 1525006
Depends on: 1569123
Depends on: 1581559
Depends on: 1596701
Keywords: sec-want

(In reply to Tom Schuster [:evilpie] from comment #6)

I wonder if we could allow only the JavaScript MIME types plus the top incorrect MIME types (text/html, application/json, text/plain, empty) and disallow everything else.

I still think this is a good idea. I could try opening a spec PR, but I get the feeling there isn't much interested in working on this by other browsers.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.