Problems with sessionStorage using local file system
I am using Firefox 83.0 64-bit on a Windows laptop.
I was hoping to prototype some website code locally (using the Windows directories) prior to testing with a proper website.
I have been unable to get sessionStorage (or localStorage) to pass variables to another page unless they're in the same Windows directory. For instance, if I create 2 very simple and cut-down test files: Test1.html and Test2.html, that contain the following JavaScript:
Test1.html window.sessionStorage.setItem ("html", element.innerHTML); alert ("posting " + window.sessionStorage.getItem ("html")); window.open ("Test2.html", "_self");
Test2.html var html=window.sessionStorage.getItem ("html"); alert ("received " + html);
then it works if the two files are in the same directory. But if Test2 is in a subdirectory, and I change the open call to:
window.open (".\\subdir\\Test2.html", "_self");
then it receives null instead of the HTML that Test1 is sending. I am guessing that there is some code that is treating the change of directory as a cross-origin issue, even though they're under the same root directory.
I appreciate that the specification may be a bit vague in this non-Web situation, but Chrome does what I would expect. I thought someone might want to take a look to check if this was an oversight or deliberate.
Chosen solution
To protect against attack pages traversing, say, your Downloads folder, there are various restrictions on file:// access. Perhaps that also affects local storage? You could try rolling back the last of these protections to see whether that helps. I'm copy/pasting from an older thread:
Firefox 68 imposed a further restrictions to prevent exfiltration of valuable data within reach of a local page, as demonstrated in an available exploit. More info:
- https://developer.mozilla.org/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp
- https://www.mozilla.org/security/advisories/mfsa2019-21/#CVE-2019-11730
If it is critical to you, you could roll back the patch as follows:
(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.
(2) In the search box above the list, type or paste uniq and pause while the list is filtered
(3) Double-click the privacy.file_unique_origin preference to switch the value from true to false
Was that it?
To mitigate the vulnerability:
If you save pages from untrusted sites in a separate folder, e.g., Downloads\Untrusted, then it would be difficult for an attack page to find any valuable content using local file links.
Read this answer in context 👍 1All Replies (3)
Chosen Solution
To protect against attack pages traversing, say, your Downloads folder, there are various restrictions on file:// access. Perhaps that also affects local storage? You could try rolling back the last of these protections to see whether that helps. I'm copy/pasting from an older thread:
Firefox 68 imposed a further restrictions to prevent exfiltration of valuable data within reach of a local page, as demonstrated in an available exploit. More info:
- https://developer.mozilla.org/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp
- https://www.mozilla.org/security/advisories/mfsa2019-21/#CVE-2019-11730
If it is critical to you, you could roll back the patch as follows:
(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.
(2) In the search box above the list, type or paste uniq and pause while the list is filtered
(3) Double-click the privacy.file_unique_origin preference to switch the value from true to false
Was that it?
To mitigate the vulnerability:
If you save pages from untrusted sites in a separate folder, e.g., Downloads\Untrusted, then it would be difficult for an attack page to find any valuable content using local file links.
That setting certainly fixed the problem, but I don't see how the Firefox 68 change fixes the security issue.
It's still possible for a locally-saved file to get a directory listing of the current location -- index.html etc., do not apply to these local file-system scenarios for some reason. The fix for "CVE-2019-11730: Same-origin policy treats all files in a directory as having the same-origin" explains "other resources in the same directory or its subdirectories no longer satisfy the CORS same-origin rule", but sessionStorage only fails for subdirectories of the root (same-directory is OK).
Maybe I've misunderstood.
How would this work:
ACProctor said
It's still possible for a locally-saved file to get a directory listing of the current location -- index.html etc., do not apply to these local file-system scenarios for some reason.
I thought scripts had to guess the names of files in order to access them. It's a big problem if they can pull a list.
The fix for "CVE-2019-11730: Same-origin policy treats all files in a directory as having the same-origin" explains "other resources in the same directory or its subdirectories no longer satisfy the CORS same-origin rule", but sessionStorage only fails for subdirectories of the root (same-directory is OK). Maybe I've misunderstood.
Hmm, I've forgotten too much about that bug by now to know whether DOM storage was even considered. Perhaps that is a separate bug to be filed. (https://bugzilla.mozilla.org/)