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.
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.
Now I know there are a lot of resources about same origin policy, but I just want a straight up answer for my specific query as I am really struggling to understand.
I am using Facebook plugins on my website, these create iframes that are only visible in the DOM when I use chromes inspect element etc.
Is there a way that I can access these iFrames properties/attributes at all, or is it a resounding "NO CHANCE!". I am spending far too much time on this and I just need to get a final verdict.
Thanks!
Javascript doesn't see the iframe content. Chrome inspector just loads 2 different websites in the same time, yours and the plugins one, so you can play with both of them.
Just curious, how would you like to change it?
In general, JavaScript cannot access iframe content from outside of the iframe, unless the page domain and the iframe domain share the same protocol and host and port. In your case, this could possibly be done using a proxy server to load the iframe content from your domain.
http://en.wikipedia.org/wiki/Same_origin_policy
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.
I've got a page with an iframe. The page and the source of the iframe are in different domains. Inside the iframe I'm using a rich text editor called CuteEditor (which has turned out to be not so cute). There are certain javascript functions in CuteEditor which try to access 'document' but the browser denies access since they're not in the same domain.
Here's the exact error:
Permission denied to access property 'document'
http://dd.byu.edu/plugins/cuteeditor_files/Scripts/Dialog/DialogHead.js
Line 1
Editing the javascript is out of the question because it's been minfied and obfuscated so all the variable names are cryptic.
Using a different editor is currently out of the question because this is a work project and this is the editor I've been told to use.
Is there a way to keep the iframe self-contained? So it does everything inside the iframe and doesn't try to break out to the parent frame?
If the child iframe is loaded from a different domain, then it will not be able to access the parent page or DOM.
However, there is a still a possible vulnerability to man-in-the-middle attack as follows. Suppose your page loads off http://yoursite.com and the iframe goes to http://badsite.org
first http://badsite.org redirects to http://yoursite.com/badpage
This is the step that requires a man-in-the-middle attack. The attacker must either be able to get between the user and yoursite.com, or control the answers to your DNS lookup. This is easier than it sounds -- anyone who has administrative control over a public WiFi access point could do it (think Starbucks, hotels, airports.) The goal is to serve the content of http://yoursite.com/badpage from the attacker's site, not your actual site.
The attacker can then serve whatever malicious code they like from the (fake) http://yoursite.org/badpage. Because this is in the same domain as the main page, it will have access to the parent DOM.
The HTML5 iframe sandbox attribute seems to be the way to avoid this. You can read the spec, but the best description might be here.
This seems to be supported on Chrome, IE10, FireFox, Safari.
The spec says that if the "allow-same-origin" attribute is not set, "the content is treated as being from a unique origin." This should prevent your child iframe from accessing any part of the parent's DOM, no matter what the browser thinks the URL is.
You shouldn't need to worry about that happening.
The only way iframes can talk cross-origin is with postMessage, and that's only possible if you're listening to that domain directly.
https://developer.mozilla.org/en/DOM/window.postMessage
We recently had a scenario in which an iframe snippet on a server A was pointing to url on server B. There were some malwares being installed by server A on some clients. Can this iframe be the cause. As in hacker injected his url in the iframe's src. What can be the alternatives to iframe etc.
Most likely you experienced XSS
If a hacker is able to change the URL an iframe points to on your site then the iframe is not the problem, your code is.
Any web site could serve up malware, but you have indicated that the hacker has attacked your site and changed the src attribute of the iframe, not the site serving the iframe contents. Even if you replaced an iframe with something else the fact that an attacker has managed to get to the data behind your web site used to generate the page means that they could not limit themselves to iframes, but embed other tactics, such as a redirect, or a hidden link which is clicked by javascript or any other type of common nasty.
Generally IFrame whose content comes from a different domain cannot access the DOM of the parent web site - due to cross domain scripting restrictions. There were lots of bugs involving browsers not implementing such restrictions properly, so an out-of-date client browser might be the cause.
Unless you're running code inside of the iFrame, which you really shouldn't be, it would be a good idea to disable that iFrame from running any code.