I have a cross origin iframe that's using indexeddb for local storage. What I want is to have my indexeddb to have the origin set to be origin of the iframe. When I visit the iframe's domain, I want to be able to access the data stored in the indexeddb for that domain.
This works fine in Chrome, however in both Firefox and Safari, I've found a problem. The iframe code is getting two different indexeddbs based on whether it's loaded in an iframe or not. I figured out what Firefox is doing, and I suspect Safari is doing something similar. Firefox is actually partitioning the indexeddb based on the union of the iframe's domain and the embedding parent's domain. (i.e. Firefox is not segmenting by the iframe's origin, but rather a combination of iframe's and the parent's origins.)
I've been poking around with various sandbox parameters on the iframe, but I haven't figured out a way around this, and there's not a lot of information about this. Is there anyway to force Firefox and Safari to just use the iframe's origin here?
This is due to state partitioning.
You can request unpartitioned state access by using the Document.requestStorageAccess() api
Related
I have a website example.com. example.com is embeded in an iframe on example2.com. I fill in some data in the iframe, this data is saved in localstorage on example.com.
Now if i navigate to examle.com, this data persists. Meaning it is sharing localstorage with the iframe, which makes sense because it is the same website, however, this only works in chrome, in firefox and safari, the data does not persist.
So to be clear, i dont want to share data between example.com and example2.com i just want the localstorage to persist on example.com regardless of it being in an iframe or being accessed directly.
Thanks
LocalStorage is intended to store data on client's browser and, because of this, stored data are equated to third-party cookies when saved by resources coming from external domains.
Currently (Jan 2022) browsers are dropping support (in terms of both availabilty and durability) of third-party cookies and you probably should expect Chrome will behave in the same way in the near future (see here).
I'm going to have several iframes on my page and I'm going to quite intensively use sessionStorage inside them. What I'm curious about is if I will have separate storages or one shared for all iframes? How do the size limits apply?
If sessionStorage is shared depends on the iframe's page and it's origin, which is the domain part of the URL. If you have a webpage at http://myserver/test.html and it is including http://thatserver/some.html via an iframe, the iframe's page has the domain thatserver. Thus the origin differs and the sessionStorage won't be shared. But if the iframe's page is http://myserver/some.html it has the same origin and therefore will share the same session storage.
Now there is an additional trick: The sandbox attribute for the iframe. If you write <iframe sandbox> without the value allow-same-origin the content of the iframe gets a unique origin. That means it would get a different sessionStorage regardless of the real origin that page has. You can write <iframe sandbox="allow-same-origin"> to sandbox the content AND let the content of the iframe to have the same origin (but only if if does have the real same origin).
Now special notes: sandboxed iframes won't support localStorage per spec. And in webkit-browsers and mozilla firefox an exception will be thrown if the sandboxed iframe content will try to access sessionStorage.
OK, I've made a test myself. At least in Chrome (44) and Firefox (40) the sessionStorage is shared among page and the iframes included if they are of the same domain and do not if they are of different domains.
I have two domains:
sub1.domain.org contains an iframe with its src pointing to the other: sub2.domain.org
On sub2:
//triggers a cross-domain security error
alert(window.parent.location.href);
//executes just fine on FF, IE, Chrome, and Safari.
window.parent.location.href = new_url;
So it appears I'm allowed to write to the parent window's URL, but I'm not allowed to read it. Is that really the standard? I just need to know why this is working as it does.
I found one answer here: Why can a child redirect a parent frame?
the Same origin policy doesn't apply here, either. By changing the url
in the address bar in your browser window, you're changing the
window.top.location.href property, too. If there were same-origin
restrictions there, the internet would be dead. You're not sending a
request to another location, you're not getting data from a
third-party resource and loading it in your page, you're redirecting
the browser to another location, which closes and clears the DOM.
But this answer prompts other follow up questions.
When we change the parent's URL, aren't we still technically modifying the parent's DOM (even if it closes it) and therefore violating the same-origin policy?
How exactly would the internet be dead if the same origin policy applied here? Surely we can differentiate manually entering URLs in the address bar from changing it via scripts on separate domains.
I understand that this case is not violating the same-origin policy, but I'm still struggling to understand exactly why. Can anyone shed additional insight as to why this is allowed?
It is not a security problem for an iframe to change the URL of a parent window. That just loads a new page into the parent window (thus killing the iframe that was contained in the original parent). There's no security issue there.
The iframe from a different origin is (as you have noticed) not allowed to access the content of a parent as that could be a security issue.
FYI, the reverse is also true. A parent frame can create an iframe and set it's .src to whatever it wants, including other domains, but cannot access the content that loads. The core issue here is that it is not a security problem to display content from other domains, but it can be a security issue to access the actual content from a different origin. So, you're generally allowed to display whatever you want, just not access it.
FYI, the ability to detect whether you are being framed and "bust" out of the frame by resetting the parent window source URL is known as "frame busting" and it is considered a content provider's right to decide whether or not they can be framed or not or who they can be framed by. There are now newer controls that specify whether a site can be framed or not so frame busting is not required in newer browsers.
I'm loading a webpage inside iframe of a background page in chrome extension. I need to fetch the content (i.e. DOM) of iframe. I'm getting protocol error. how to overcome this situation, any workaround.
"Unsafe JavaScript attempt to access frame with URL https://swym.3ds.com/ from frame with URL chrome-extension://ohhaffjbbhlfbbpcdcajbkeippadmipk/back.html. The frame requesting access has a protocol of 'chrome-extension', the frame being accessed has a protocol of 'https'. Protocols must match."
I'm trying to implement a desktop notification for the above site, hiding the process from user eye.
I tried using XMLHTTPRequest and Jquery GET, unfortunately my site loading is unstandard, it doesn't work as intended.
Any suggestion on this topic will be very helpful.
It seems you're facing Cross-origin resource sharing issues. Do a quick check for resources loaded with protocols, convert http://www.example.com resources to //www.example.com Also refer MDN CORS Article
Javascript cannot access content on another domain as it poses security risks. If you have control over the domains, you may use postMessage to overcome this. Take a look at this link
Our web application (based on HTML5, SVG & JS) runs fine in all the browsers except Google Chrome.
In Google Chrome, the normal javascript events run fine, however, all the javascript events attached to the iFrame are not executed. We get the error in the console:
Unsafe JavaScript attempt to access frame
At the moment, the application is locally hosted and this problem cropped up during inhouse testing.
Googling this brings up lots of posts but none suggests any concrete solution. Any suggestions?
As an additional security measure, Chrome treats every "file" path as its own origin rather than treating the entire "file" scheme as a single origin (which is what other browsers do). This behavior applies only to "file" URLs and you can force Chrome to revert to a single local origin (like other browsers) by passing the --allow-file-access-from-files switch at startup.
You can find more information on the risks associated with local origins described here: http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html
Please make sure that both the iframe and main page are using the same protocol (i.e. both https or both http, but not mixed) and are on the same domain (i.e. both www.example.com and not example.com and dev.example.com). Also there's the possibility that something tries to use the file:// protocol, which will also cause this message.