1565261 - ff 68 refuses to process a xslt schema for a resource loaded via file:// schema

Status: NEW

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

Description

[stelle]

Attachment: bugzilla.xml

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

Steps to reproduce:

load the xml from file system via file:// protocol.

Actual results:

I get an error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///D:/My%20documents/%D0%A1%D0%B2%D0%BE%D0%B8/homepage/system/resource.xsl. (Reason: CORS request not http).

Expected results:

xsl should be loaded and applied to the existing xml file.

Comment 1

[stelle]

Attachment: resource.xsl

Comment 2

[stelle]

it worked perfectly until i updated to 68 version

Comment 3

[[:philipp]]

hi, this is likely fallout due to the following privacy/security fix in firefox 68: https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730

you could try to change privacy.file_unique_origin to false in about:config, restart firefox and see if this can make a difference (please note that this makes you vulnerable to the described security problem though).

Comment 4

[stelle]

Yes, that solves the problem.
Thank you very much.

Comment 9

[Andrea Marchesini [:baku]]

Note that other browsers behave at the same way, blocking the loading of resource.xsl.

Comment 10

[stelle]

yes, they do. but i never understood why.
i'm totally ok with blocking the loading for security reasons, but i don't get it why it should not work for legitimate cases, such as mine.

Comment 11

[Boris Zbarsky [:bzbarsky]]

The issue is that an XML file that links to an XSLT sheet can then extract a fair amount of information from that XSLT sheet. If they're different origins, that's a same-origin policy violations, which is why XSLT stylesheets are restricted to being same-origin with the document they style.

Comment 13

[Richard Moldwin]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #11)

The issue is that an XML file that links to an XSLT sheet can then extract a fair amount of information from that XSLT sheet. If they're different origins, that's a same-origin policy violations, which is why XSLT stylesheets are restricted to being same-origin with the document they style.

In my case, the XML file and xslt are on the same computer, same folder. It still fails. This happens whether I load the file/browser from a local program, or the user just drags the xml file from a local folder into FF.

Regarding the priority - This new bug breaks a critical workflow for us for creating medical guidelines. FF was the only remaining browser that supported xslt, and now there are none. If this is not fixed, we will have to rewrite our software to bypass FF.

Comment 14

[Boris Zbarsky [:bzbarsky]]

In my case, the XML file and xslt are on the same computer, same folder.

Right, and two files, even in the same folder, are no longer considered same-origin, for various reasons. Think things like the Downloads folder.

FF was the only remaining browser that supported xslt

Just to be clear, we still support it, but the same-origin policy for file:// was made more restrictive, matching other browsers. You can still use XSLT with no problems by running a local web server... Depending on your threat models you may also be able to set the pref to go back to the old file:// behavior to mitigate the immediate issue (see comment 3), but we don't guarantee that this will keep working forever.

It's not entirely clear at this point how, and whether, the old behavior can be re-enabled without exposing increased attack surface. It's entirely possible that the answer is "it can't be".

And as you note, the fact that no other browser supported this unfortunately makes it less likely that we will jump through significant hoops (possibly opening ourselves to security bugs) to support it...

Comment 15

[RolfBly]

(In reply to Richard Moldwin from comment #13)

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #11)

FF was the only remaining browser that supported xslt, and now there are none. If this is not fixed, we will have to rewrite our software to bypass FF.

FYI, I found this page googling the phenomenon described.

In my case FF and Chrome wouldn't render XML/XSL anymore (xml and xsl in same directory), but IE and Edge still worked. [:Philipp]'s workaround does fix it, if you can live with the vulnerability and want to stick to FF.

Comment 17

[Damian Yerrick]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #14)

You can still use XSLT with no problems by running a local web server...

Which local web server could a user of Firefox for Android try using?

Comment 18

[Boris Zbarsky [:bzbarsky]]

How often do Android users use the file:// scheme?

Comment 19

[François]

Hello,
what about reading a text file "<target_file>.cors", or ".cors" if first one not present (default for all files in the same directory), that would contain an "Access-Control-Allow-Origin" line?
For example, in the case given at the beginning of this bug, a file "resource.xsl.cors" containing "Access-Control-Allow-Origin: bugzilla.xml" or "Access-Control-Allow-Origin: *" (with relative url having the target file directory as base).

Comment 20

[François]

Sorry that would not be enough: user can be persuaded into dowloading such a .cors file...