Closed
Bug 1233964
Opened 10 years ago
Closed 7 years ago
iframe embedded in ui/frame isn't allowed to read localStorage values
Categories
(Firefox :: Extension Compatibility, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: andreas, Unassigned, NeedInfo)
Details
Attachments
(1 file)
|
6.24 KB,
application/x-xpinstall
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.4.0
Build ID: 20151103235259
Steps to reproduce:
I'm programmatically adding a ui/toolbar to firefox. That toolbar hosts a ui/frame.
My index.js:
---
var self = require('sdk/self');
var { Toolbar } = require("sdk/ui/toolbar");
var { Frame } = require("sdk/ui/frame");
var frame = new Frame({
url: "./test.html"
});
var toolbar = Toolbar({
name: "test",
title: "test",
items: [frame]
});
---
The "frame" points to "data/test.html" and this file contains the following lines:
---
<!doctype html>
<html lang='de'>
<head>
<meta charset='utf-8' />
<title>frame iframe test</title>
<style>
html, body {
padding:0;
margin:0;
}
iframe {
border-width:0;
padding:0;
margin:0;
}
</style>
</head>
<body>
<iframe src='https://www.as.tl'></iframe>
</body>
</html>
---
So it contains an iframe pointing to "https://www.as.tl". On "https://www.as.tl/index.html" I have the following contents:
---
<!doctype html>
<html lang='de'>
<head>
<meta charset='utf-8' />
<title>test</title>
<style>
html,body {
margin: 0;
padding: 0;
}
</style>
</head>
<body>
<b id='foo'>nope</b>
<script>
(function() {
document.querySelector('#foo').innerHTML = 'test1';
localStorage['foo'] = 'test3';
document.querySelector('#foo').innerHTML = 'test2';
document.querySelector('#foo').innerHTML = localStorage['foo'];
})();
</script>
</body>
</html>
---
all it contains is a bold "nope" which will be replaced with the localStorage value of key 'foo' which is 'test3'.
If you open that website using firefox it will display "test3" just fine and that's the expected behaviour inside the frames iframe.
Actual results:
When I install my extension all I see is "test1" inside the ui/frame. So javascript execution seems to work but fails whenever I try to access "localStorage" inside the "index.html" hosted at https://www.as.tl/index.html. I tried with a different server, just in case,
but the outcome is the same.
I tried my extension with firefox 43 which I got from: http://ftp.mozilla.org/pub/firefox/releases/43.0/linux-x86_64/en-US/firefox-43.0.tar.bz2
And I ran my extension with jpm:
> jpm -b /home/a/Downloads/firefox43/firefox/firefox run
I also tested it with firefox 44.0b1 but had the same result:
> jpm -b /home/a/Downloads/firefox440b1/firefox/firefox run
Whenever the extension is executed I will get the following message in the browser console:
> SecurityError: The operation is insecure.
and it points to line 18 of my "index.html" at https://www.as.tl which is:
> localStorage['foo'] = 'test3';
So why is this operation insecure? When I access https://www.as.tl/index.html it's working and not considered insecure. And it's not
because of the action of adding new values to localStorage but even:
> document.querySelector('#foo').innerHTML = localStorage['foo'];
leads to this "insecure" message when executed inside the iframe which is embedded in the ui/frame.
With the page-worker I can set and read localStorage contents just fine:
---
var pageWorker = require("sdk/page-worker").Page({
contentScript: "localStorage['foo'] = 'test4';self.postMessage(localStorage['foo']);",
contentURL: "https://www.as.tl",
onMessage: function(event) {
console.log(event);
}
});
---
That will work but would overcomplicate things a lot as I would need to pass around several messages in my use-case.
I believe it's a bug. If not please close the ticket.
Expected results:
I expected an iframe to be able to read its own localStorage values without getting the "SecurityError: The operation is insecure." error.
|
Reporter | |
Updated•10 years ago
|
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
|
||
Comment 1•9 years ago
|
||
I am also getting this.
We have an application that stores information in localStorage, which is accessed by a cross-origin iframe. When a user has configured the privacy settings to block third-party cookies other than visited websites, the iframe receives SecurityError: The operation is insecure.
The application provides user control over whether cookies are enabled on particlar websites, so that website can comply with the "opt-in" requiremnets of EU data protection law. It uses localStorage so that no personal data is communicated from the user's device to external servers. The information is purly used for this purpose and the application is entirly privacy enabling.
If localStorage is limited to first-party script then user consent information would have to be delivered to servers which allows unscrupuulous actors to gather a user's web history without their consent.
Restriction on third-party cookies are fine becausse these are sent on every HTTP request. Although localStorage can be misused to regenerate cookies that a user has removed, it can also deliver privacy enabling applications also, by not requiring the broadcasting of web history data to external servers.
The way to fix the privacy issues around tracking is to implement the DNT javascript API (and demand legal backing for the signal), not further reduce the functionality of the web platform.
|
||
Updated•9 years ago
|
Component: Security: UI → Untriaged
Product: Core → Firefox
|
||
Updated•9 years ago
|
Component: Untriaged → Extension Compatibility
|
|
||
Comment 2•9 years ago
|
||
Does this issue still persist for you on the current release 47.0 or Nightly 50.0a1?
If so, please provide an updated test case as the url's provided lead to this site cant be reached errors.
Flags: needinfo?(andreas)
|
||
Comment 3•7 years ago
|
||
Mass-closing old Extension Compatibility bugs that relate to legacy add-ons or NPAPI plug-ins. If you think this bug is still valid, please reopen or comment.
Sorry for the bug spam, and happy Friday!
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•