How can an IFRAME with URL https://domain/ access the DOM of the parent frame which has URL http://domain/ (HTTPS calls HTTP)?
Both frames will cooperate. The domain is the same in both frames, just the protocol is different. Setting document.domain is not allowed as that would allow for XSS attacks coming from other untrusted frames.
As an alternative to accessing the DOM it would be enough to send a message (containing a single integer). Notice, that the postMessage API only works in IE8+. I need IE6+.
Is easyXDM an option. It supports postMessage for browsers with support, and falls back to other mechanisms for older browsers. Some of the mechanisms are a bit hacky but they work.
But why do you want to have a secure iframe on an insecure page?
Related
I have a frame that looks like this: <iframe srcdoc="*insert HTML here*"></iframe>.
The frame may have some javascript in it and that's okay.
How could I prevent the contents of that frame from connecting to the network?
This includes:
- Javascript's HTTP requests and WebSocket connections etc
- Remote resources referenced in CSS
- External files in the HTML code
Is there some kind of sandbox rule to disable remote connections or do I have to regex all of that out? If so, what should I watch out for when applying the regex?
There is currently no reliable way of accomplishing this.
The sandbox attribute cannot apply the type of restriction you are trying to apply here. A Content-Security-Policy can (with some difficulty), but there is currently no way of reliably applying such a policy to an <iframe> that has its contents set by the srcdoc attribute, as there is no way of simulating HTTP headers for such a document. Indeed, an iframe with srcdoc is simply treated as part of the page which embeds it, and inherits any Content-Security-Policy from that page!
The W3C draft specification "Content Security Policy: Embedded Enforcement" has proposed a csp attribute. In the future, this might be usable to apply restrictions to such a document.
In the meantime, however, you will probably need to serve this content through a sandbox domain, or rethink your design.
After reading this compendium of methods here Ways to circumvent the same-origin policy it's apparent that any workaround requires modification of the target iframe code to get communications across domains.
Unfortunately on this project I'm working on I may only modify the parent page's code, the iframe is provided from another source and is untouchable by us. Are there any methods that don't require modifications to the iframe code?
The only solution then is to fetch the iframe content from your server, either through a proxy or through specific code, and serve it yourself so that the browser only sees one origin.
But be aware that this usually breaks the rules or contract of normal use of the site providing the iframe. If they didn't include CORS headers to allow inclusion and access, there's probably a reason.
No, there cant be such a method, that would kill the security.
It's possible with
$('#iframe_id').contents().find('.stuff_to_modify).addClass('whatever');
But it's also possible using window.postMessage events, by sending a do_something message to a script from the iframe, which does the modifications when the message is received (adds that class).
I was wondering which is the way I should go, and what are the differences between these two methods (drawbacks, advantages).
The jQuery method seems nicer because I don't need to include any script in my iframe anymore
The major difference between window.postMessage and jQuery sample you gave is that, postMessage enables cross-origin communication.
Meaning, if a Parent page which hosts the iframe is from domain A, while the content of the iframe is from domain B, then postMessage allows you to communicate while the jQuery approach will result in the security error.
The link you provided is a java script wrapper to window.postMessage implementation of the browser and falls back to window location hash polling for browsers that do not support it. Other benefits are listed in your link itself.
So, if the two pages are from same origin, i.e served from same domain, then you can go the jQuery approach itself. If it is from two different origins, you may have to use the JS wrapper.
I have a web app in http://domain1/app1/called.html, and I want to embed that application inside http://domain2/app2/caller.html with an iframe (or a popup, it's the same)
the user should be able to interact with called.html, until they press a certain button, in that case I need to tell caller.html that the user selected an item from called.html
I tried implementing it with javascript.
in called.html I encode the data in json, and then I execute a "called_callback" javascript function in caller.html, passing the json as a parameter.
if called.html was called with a popup, I issue window.opener.called_callback( jsonData ), if it's an iframe I just issue parent.called_callback( jsonData )
having caller.html and called.html in the same domain everything works fine, but from different domains I get the following errors:
permission denied (on IE6)
and
Unsafe JavaScript attempt to access frame with URL [..]/caller.html from frame with URL [...]called.html. Domains, protocols and ports must match. (on google chrome)
Is it possible to overcome this limitation?
What other way of achieving it can you think of???
I guess caller.html could implement a web service, and I could send the result calling it, but the page caller.html would have to poll in order to detect any change...
So how can one application communicate with another one in a different domain to signal an event???
You can use JSONP to call resources from one domain to another.
You can use window.name as ~2Mb text transfer between cross domain frames for older browser.
Or for modern browser you can use window.postMessage to communicate string data between the 2 frames.
But you need some cooperation from the domains for these techniques to work.
You should look into using JSONP. It is fully supported in jQuery if you are using that particular framework. It allows you to use JSON across domains.
Thanks to both answer I found the following:
http://benalman.com/code/projects/jquery-postmessage/docs/files/jquery-ba-postmessage-js.html
http://benalman.com/projects/jquery-postmessage-plugin/
jQuery postMessage enables simple and
easy window.postMessage communication
in browsers that support it (FF3,
Safari 4, IE8), while falling back to
a document.location.hash communication
method for all other browsers (IE6,
IE7, Opera).
With the addition of the
window.postMessage method, JavaScript
finally has a fantastic means for
cross-domain frame communication.
Unfortunately, this method isn’t
supported in all browsers. One example
where this plugin is useful is when a
child Iframe needs to tell its parent
that its contents have resized.
I'll have a look at it...
here's a very complete document that analizes the different approaches...
http://softwareas.com/cross-domain-communication-with-iframes
another solution to have a look at
http://easyxdm.net/
with a sample
http://easyxdm.net/wp/2010/03/17/setting-up-your-first-socket/
When creating iFrame dynamically (javascript) on IE and trying to access its document, access denied error is issued (because its source is not on the same domain as the containing html).
I think I read somewhere that P3P header can lower this restriction (usually it is used for 3rd party cookies). Can anyone explain how to do it for dynamically created iframe (or point me to this data)?
No. P3P has no relation to the JavaScript Same-Original Policy, which cannot be circumvented short of a security hole in the browser or the remote site.
You may have to proxy the iframe content through your own site, if that's possible.