Risk of permitting cross-origin for local files only?

Add-ons Development
1

I asked part of this question under a different area here but this question focuses on the security risk.

I have a web extension that, in certain instances, uses an iframe within a local HTML page, that loads another local HTML page. Since I build this in my free time, I do it in pieces over time; and this piece was working several months ago but now has a cross-origin issue even though the files are from the same origin. The two could reference one another’s window previously; because the iframe file was in a subdirectory of the directory containing the parent document; but that no longer works unless security.fileuri.strict_origin_policy is set to false.

According to the now obsolete article “The Same-origin policy for file: URIs” at https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs, this at least worked in the past. And I know it did, because my code used to work.

I can still load other local resources such as an image, PDF, or audio file, directly into a local HTML page via a relative path; and iframe scripts execute, as long as they are same-origin under these obsolete rules; but the HTML file in the same directory is treated as a different origin when in an iframe and when attempt to communicate with the parent window.

I thought script execution within an iframe required same origin; so, I don’t understand why for communication the two are considered of different origins, when the script is permitted to execute.

My question is what is the risk to the user of an extension if this configuration setting is set to permit cross-origin for local files only? The extension I am working on requests several API permissions.

I plan on recommending that the user set up a separate profile for the extension and use it like a desktop application rather than for normal internet usage. They could work offline but need to check for updates and can download free resources for the extension tool from my web site through the extension itself.

Does this leave the user at risk and is there anything that should be done to protect them, or is it better to not do this at all? It is not essential to the extension tool, but makes certain items easier for the user to access and validate.

Perhaps, if it is a risk to do this, since this is in an extension, a hidden tab could be used that is same origin, rather than an iframe. I guess a hidden tab and a hidden iframe are much the same in terms of memory usage; but I’m not 100% certain about that.

Thank you.

1 Like
2

What if you keep

security.fileuri.strict_origin_policy

set to true and and only change the newer preference

privacy.file_unique_origin

to false?

The risk with this newer preference is that a malicious file saved in, say, the Downloads folder, could use XHR to read other files in the folder and subfolders. All untrusted saved web pages need to go into individual or at least low risk shared folders.

I think changing the older one has much more troubling implications but I haven’t researched it in recent years.

3

Thank you. Unfortunately, that setting doesn’t seem to work, for the iframe cannot be read by the parent.

As an aside, will XHR and fecth work for local HTML files with this setting? I’m pretty certain I have tried this a number of times because I was interested in setting a header to get a new file and bypassing the cache–hot reloading; and it won’t work for a local file. But I had not changed the setting.

If the user does this in a separate profile, will the config settings apply only to that profile? It appears so.

When you write a malicious file can read other files in the folder and subfolders, do you mean any file or other HTML files? I ask because with the preference set to true, a local file can load other files in the same origin but cannot read an HTML file loaded in an iframe. I don’t know enough to understand it all.

It sounds rather complex, for how could that malicious file open the correct profile that has the risky setting? Do you know where I could read more about this? Not to do it, of course, but to understand the risks. Thank you.

4

You can find more info on the privacy.file_unique_origin change here: https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730

A separate profile is always a good idea for risky behaviors, but if it is using the same set of folders to load local files, I’m not sure it would mitigate this one.

5

Thank you for the link. It refers to security.fileuri.strict_origin_policy and explains why my old code stopped working, that is, why the parent can no longer read the iframe content.

If I understood correctly, the user must first open a malicious HTML file locally, after which it may read the content of other same-origin HTML files it opens in an iframe or object, if it can first guess the filenames, which in the case explained was a phone app that had a very predictable naming convention.

Thus, it depends where that malicious file is saved and the configuration settings of the profile in which it is opened. In my particular case of having a separate profile for the extension and using it as suggested this will not be a risk. However, if the user were to use that separate file for other purposes and open a malicious file, then there could be a problem.

I can see the risk and why the rules had to be changed. The bigger risk is opening files the soruce of which one doesn’t know.

It was helfpul to read that link. Thanks again.

6

I was thinking further about this and had a thought concerning how to mitigate the risk involved.

This extension is to function like a desktop application and needs only to be able to check for extension updates and, at times, connect to my site if the user wants to download free resources that run “in” the extension. There is no need for a continuous connection to my site. The extension doesn’t require external resources and there are no ads or feeds of any kind.

In this scenario, could the web request API be used to block all other activity, such as attempts to send information out or link to any external resources?

Thus, if a user was to open a malicious file that successfully opened other local files in an iframe and read the information for upload to a web site, the attempt would be intercepted and the user warned of the attempt.

The extension would be run in a separated / dedicated profile that has the configuration setting discussed above set to false.

Thank you.