Bugzilla

[originally submitted via email, but the autoresponder asked to resubmit via bugzilla]
While testing a cookie auto deletion addon, i came across what seem to be a cookie/storage permission bypass.

Steps to reproduce:

0. As usual serve the attached files using a local webserver (like python3 -mhttp.server) and access them on a
   non localhost ip.

1. I have tested this with a fresh firefox nightly (116.0a1 (2023-06-16)(64bit).
2. In the fresh profile set cookie blocking to "custom" and select to block "All cookies".[1]
3. Confirm that normal access to local storage is blocked by using the attached test-noiframe.html
3a: Access to the storage APIs gives a "DOMException: The operation is insecure.", the storage tab in developer tools show no saved data.
4. But Using the attached test2.html give unblocked access to local storage.

Expected Result:
Firefox blocks storage access the same as when using the non iframe version of the test. No data stored.

Actual Result:
The storage apis work and ignore the setting to block the access:
* No exception on usage
* When entering data in the textbox and pressing save, on reloading the page, the page can retrieve the data.
* The saved data is not visible in developer tools, but even after restarting firefox the page can still read back the data.
* The origin with the saved data is shown in "Manage Cookies and Site Data" as having used storage.

I have not tracked done the regression point, but using firefox 100, the blocking works and the api access gives the expected exceptions.
This seems to be a recent regression.

The core part of test2.html is as follows. It seems by just using the contentWindow of a otherwise defaulted iframe,
the blocking of the storage api is evaded.

<iframe id="preview" name="preview"></iframe>
<script>
let p = document.getElementById('preview');
let currentData = p.contentWindow.localStorage.getItem('blah');
document.getElementById('odata').innerText = currentData;

function setTest() {
    p.contentWindow.localStorage.setItem('blah', document.getElementById('idata').value);
}
</script>

From looking at the profile directory the local storage seems to be attributed to the origin used to access test2.html.

storage.sqlite
INSERT INTO origin VALUES(2,'','192.168.123.123','http://192.168.123.123:4567','L9',9,1686945337316151,1,0);

storage/default/http+++192.168.123.123+4567/ls/data.sqlite
INSERT INTO "database" VALUES('http://192.168.123.123:4567',9,1686944680773745,0,6144);


I've played around a bit if this also allows evading storage isolation, but i did not the storage to leak across.
But this still evades supported data privacy settings.


 [1] The problem also manifests with other global settings and blocking the specific origin.

[originally submitted via email, but the autoresponder asked to resubmit via bugzilla]
While testing a cookie auto deletion addon, i came across what seem to be a cookie/storage permission bypass.

Steps to reproduce:

0. As usual serve the attached files using a local webserver (like python3 -mhttp.server) and access them on a
   non localhost ip.

1. I have tested this with a fresh firefox nightly (116.0a1 (2023-06-16)(64bit).
2. In the fresh profile set cookie blocking to "custom" and select to block "All cookies".[1]
3. Confirm that normal access to local storage is blocked by using the attached test-noiframe.html
3a: Access to the storage APIs gives a "DOMException: The operation is insecure.", the storage tab in developer tools show no saved data.
4. But Using the attached test2.html give unblocked access to local storage.

Expected Result:
Firefox blocks storage access the same as when using the non iframe version of the test. No data stored.

Actual Result:
The storage apis work and ignore the setting to block the access:
* No exception on usage
* When entering data in the textbox and pressing save, on reloading the page, the page can retrieve the data.
* The saved data is not visible in developer tools, but even after restarting firefox the page can still read back the data.
* The origin with the saved data is shown in "Manage Cookies and Site Data" as having used storage.

I have not tracked done the regression point, but using firefox 100, the blocking works and the api access gives the expected exceptions.
This seems to be a recent regression.

The core part of test2.html is as follows. It seems by just using the contentWindow of a otherwise defaulted iframe,
the blocking of the storage api is evaded.
```HTML
<iframe id="preview" name="preview"></iframe>
<script>
let p = document.getElementById('preview');
let currentData = p.contentWindow.localStorage.getItem('blah');
document.getElementById('odata').innerText = currentData;

function setTest() {
    p.contentWindow.localStorage.setItem('blah', document.getElementById('idata').value);
}
</script>
```
From looking at the profile directory the local storage seems to be attributed to the origin used to access test2.html.

storage.sqlite
INSERT INTO origin VALUES(2,'','192.168.123.123','http://192.168.123.123:4567','L9',9,1686945337316151,1,0);

storage/default/http+++192.168.123.123+4567/ls/data.sqlite
INSERT INTO "database" VALUES('http://192.168.123.123:4567',9,1686944680773745,0,6144);


I've played around a bit if this also allows evading storage isolation, but i did not the storage to leak across.
But this still evades supported data privacy settings.


 [1] The problem also manifests with other global settings and blocking the specific origin.