Return a network error for requests whose type is "script" with additional bad MIME types (round 2)
Categories
(Core :: DOM: Security, defect, P3)
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
Comment 1•7 years ago
|
||
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.
Updated•7 years ago
|
Reporter | ||
Comment 2•7 years ago
|
||
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.
Updated•7 years ago
|
Comment 3•7 years ago
|
||
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).
Comment 5•5 years ago
|
||
New data since bug 1510225 landed: https://mzl.la/2GxHc9Q. "application/json" is huge probably JSONP endpoints.
Comment 6•5 years ago
|
||
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.
Reporter | ||
Comment 7•3 years ago
|
||
The probe name changed since comment 0 so here's an updated telemetry link:
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2021-08-24&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F92&measure=SCRIPT_BLOCK_INCORRECT_MIME_3&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2021-08-09&table=0&trim=0&use_submission_date=0
Comment 8•2 years ago
|
||
(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.
Updated•2 years ago
|
Description
•