Open Bug 1565261 Opened 3 years ago Updated 7 months ago

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

Categories

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

68 Branch
defect

Tracking

()

People

(Reporter: stelle, Unassigned)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [domsecurity-backlog1])

Attachments

(2 files)

Attached file 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.

Attached file resource.xsl

it worked perfectly until i updated to 68 version

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).

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

Duplicate of this bug: 1565764
Duplicate of this bug: 1565604
Duplicate of this bug: 1566029
Component: Untriaged → DOM: Security
Product: Firefox → Core
Duplicate of this bug: 1566192

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

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.

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Regressed by: CVE-2019-11730
Duplicate of this bug: 1566412
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]

(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.

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...

(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.

Duplicate of this bug: 1588598

(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?

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

Severity: normal → S3

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).

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

Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.