1570629 - JavaScript module files are blocked from loading in saved web pages

Status: REOPENED

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

Description

[DavJCobb]

Attachment: A bare-minimum test case: an HTML file that includes a JS module, which does nothing other than log to the console.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Create an HTML file consisting solely of a script tag which includes a JavaScript module file -- a script that does nothing other than to log to the console will do.

Save that HTML file as a "Web Page, complete" -- that is, a web page linked with its assets using the Windows "Connected Files" functionality https://docs.microsoft.com/en-us/windows/win32/shell/manage#connected-files, with those assets reorganized into a subfolder by Firefox.

Open the saved web page.

(Note: It doesn't matter whether you put the web page and its module on a local HTTP server and save it from there, or just run it from your hard drive and save it. Firefox treats the save process the same way for both, and you get the same results for both.)

Actual results:

The module didn't run, and the debug console showed a "Cross-Origin Request Blocked" error. This is consistent with changes made to Firefox's handling of file:/// URIs in response to CVE-2019-11730. HOWEVER,...

Expected results:

...it looks (given that the relevant Bugzilla bug is still private) like the problem with CVE-2019-11730 was that separately-saved files, with no intentional relation to one another, could interact with each other if they ended up in the same folder e.g. a Downloads folder. Saved web pages are a different situation: they have their assets reorganized into a subfolder, with that subfolder named such that Windows treats the saved web page and the folder as a single unit; there is an intentionally-constructed relationship between the saved web page and its assets.

It looks like JavaScript modules will always break in "complete" web pages saved to the disk; they cannot be included by the web page and presumably cannot include each other. I'm wondering if this could be avoided by having Firefox treat the Connected Files folder as same-origin for the saved web page.

Comment 1

[Daniel Veditz [:dveditz]]

Javascript module loading requires CORS and file: doesn't support CORS. Sounds like another case where we have to make an exception. (what happens in Chrome?)

Comment 2

[Jonathan Kingston [:jkt] he/him]

It looks like Chrome doesn't support this either:

Access to script at 'file:///.../moduletest/testmodule.js' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.

Comment 3

[Jonathan Kingston [:jkt] he/him]

As Chrome doesn't support loading modules this way and also behaves the same for workers, it's clear that modern JavaScript developent will now require a local server to test on, which is the improved security world we now live in.

Comment 4

[Boris Zbarsky [:bzbarsky]]

This isn't about "JavaScript development". This is about the user-facing "save a web page" feature, and we generally aim to make that work in various ways. We are in control of the exact data being saved for both the HTML and the module involved, so we could add annotations that say "this particular module is OK to load from this particular file" without comporomising security. We should consider doing something like that. The proposal at the end of comment 0 is not in fact unreasonable.

Another alternative would be to rewrite modules, which we know we won't be able to load from file://, to data: URLs during the "save as, complete" process, since that's rewriting all the URLs anyway.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Two other notes:

1. Yes, "save as, complete" is best-effort. If the page tries to access the server dynamically it will fail.
2. There is a general push on the web to move all script-loading over to modules instead of using normal script tags. That means that if we don't address this bug the "save as, complete" feature will effectively become useless for any page that actually uses scripts. Whether that means that we address this bug, allow the feature but have it save broken pages, or disable the feature is a product+UX decision, and should be coordinated with people outside the security team.

Comment 6

[Daniel Veditz [:dveditz]]

That conflicts with our decision to wontfix the equivalent "worker" bug. Shouldn't we make the same decision for both?

Comment 7

[Jonathan Kingston [:jkt] he/him]

I was still able to see this as broken in Chrome by this STR:

1. Download the STR files
2. open http-server path
3. open chrome on the html file
4. save as to a new directory
5. open the new html path

Chrome still has the same CORS error as before.

Comment 8

[Daniel Veditz [:dveditz]]

We fixed WOFF: bug 1565942
Didn't fix workers: bug 1565672

Comment 9

[Boris Zbarsky [:bzbarsky]]

That conflicts with our decision to wontfix the equivalent "worker" bug.

The worker bug was not quite equivalent, since it was in fact talking about local development, not the "save page" end-user feature. Just to be clear, those are very different scenarios, with very different security properties. For the "save page" case we control all the data and can restrict things to access into the subresource dir from the main saved file, etc. In particular, we do not have to allow sibling file access, or access to arbitrary files in child dirs not associated with the original web page, which were the major security concern for the old file:// policy.

But yes, for pages that involve workers having them work in the "save page" case would be good too, imo. In fact, having separate iframes continue to talk to each other would be good!

Maybe this means we should change how we store our saved files (e.g. moving to MHTML instead of just files on disk).

I was still able to see this as broken in Chrome by this STR:

Yes, Chrome has this bug too. That does not mean we should have it, imo.

Comment 10

[Daniel Veditz [:dveditz]]

The proposal at the end of comment 0 is not in fact unreasonable.

Note that not treating saved resources as same-origin in fact fixed a long-standing same-origin-violation vulnerability if an attacker could convince a user to save a web page and then re-open it on disk. We would need to be careful to limit this to workers and modules that were in fact same-origin on the web, and not workers and modules that failed to load because of SOP.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Hmm. Yes, we'd need to teach webbrowserpersist about the CORS-only semantics of some loads. This is already a problem to some extent...

Comment 12

[Tom S [:evilpie]]

We would also need to fix import statements inside the module JS code. Of course fixing dynamic imports is basically off the table.

Comment 13

[Boris Zbarsky [:bzbarsky]]

We would also need to fix import statements inside the module JS code.

Separate bug, please. Again, "save page, complete" is kinda best-effort...