I have a iframe in my webpage (facebook like etc.). can i prevent a break out from this iframe?
I did not the iframe can data be read at my session / forms etc
If you're worried about security: No need. An iframe containing an external page can not read sessions, or submit forms, in the parent page. The Same Origin Policy prevents that.
Other than that: Preventing frame busting is a complicated task. See this question for some of the complexities, and a working code example for a "frame buster buster".
Related
Is there a way to create a Chrome extension to trick a site loaded in an iFrame into thinking it's not in a frame?
We load clients' sites into an iframe for demos, but some resources get blocked due to them disallowing being loaded in an iFrame. We'd like to load these sites into a frame as though you were browsing directly to the site in a standalone tab.
You should use the Chrome's webRequest in order to intercept the server response. See the API. Here you go for onHeadersReceived event where you are in control of any response headers => you need to remove X-Frame-Options header from the response.
That's pretty much it, if this is the only problem in loading those sites.
However, for the sake of completeness, in order to fully trick the browser (which you most likely do not need) you need also to inject a script into every page that would clear up some things like window.parent by simple removing them from window object and some other things like origin etc. However removing the header would work for 99.9999% of your use cases.
I've seen a bunch of posts on here about google analytics tracking and iframes and how there could be some issues. Also have seen this: https://developers.google.com/analytics/devguides/collection/gajs/gaTrackingSite#trackingIFrames
I have tracking code in the parent website that I don't care about, and I have tracking code in the page that's embedded in the iframe that I do care about. The iframe content is a completely different domain.
I was wondering if the iframe page will be able to get all the information about demographics and properly be able to send data up to Google for event tracking and whatnot. Again, I don't care about the parent at all in this case. Just that the google analytics code in the iframe works completely on its own.
I feel like the article I posted above from Google is relevant for users that want to somehow link the analytics in the iframe with the analytics in the parent, but I could be mistaken?
The documentation describes exactly what you have to do. It really boils down to:
Load the iframe using _getLinkerUrl to link the visit inside the iframe with the visit on the top frame
Use P3P headers on the iframed page to work around stupid internet explorer.
I would add some notes:
Even if you don't care about the top level page you should add a tag into it, if you don't you can't use _getLinkerUrl and you lose the traffic source, etc. If you don't use _getLinkerUrl GA inside the iframe will think it's a brand new visit referral from the top level page.
Setting cookies inside an iframe, in a third-party domain is the definition of a third-party cookie. Because of that any browser that is set to block third-party cookies will block the GA cookies and GA won't work. This include Safari (both Desktop and Mobile) that are set to block third-party cookies by default. So if visits using Safari or iDevices are important for you (likely these days) this tracking won't probably give you good results. The only solution is to eliminate the iframed page, either put it in your domain or open it in a new window/tab.
Is there a way of filtering the data of an iframe output?
For example I'll do an iframe on http://net.tutsplus.com/tutorials/python-tutorials/python-from-scratch-creating-a-dynamic-website/ and I only want to print the div with tutorial_image class. Is that possible?
Iframes sourced from other domains are subject to the Same Origin Policy - this prevents the host page from messing with them. This is a security feature that can be turned off in your browser settings -- but you cannot control this for other users.
Looking at a few advertising companies (DoubleClick, Atlas), I've come across the concept of iframe buster files, that are hosted on the same host as the ad publisher (one example: http://www.adopstools.com/ibusters/atlas/atlas_rm.htm, and there's a lot of JS code that works with that page).
I read that they're used to dynamically resize the iframe. Is that all there is to iframe busters? Does hosting them on publisher's host help with JS cross-domain restrictions?
Added: I'm referring to the use case described here: http://blog.operative.com/?tag=iframe, and not just changing the iframe source document to the top level.
This is done for "take over ads". We use iframes (ADI - iframe vs ADJ - javascript) for a few reasons:
1 - they slow down the loading of your page content.
2 - they can break javascript on your page causing your page to stop functioning properly.
3 - worse case: they inject malicious code.
Using the iframe (ADI) approach the ads are isolated into their own document and can't interfere with the main web page.
However, there are cases when your marketing team wants to run take over ads. They are ads that expand outside their iframe window. For these ads the "iframe busting" approach was setup by most of the top advertising vendors. This approach requires you to host a file on your side that the ads can interact with and by pass the cross-domain restrictions of browsers.
Here is a comprehensive list of these files: http://www.adopstools.com/?section=miscellaneous&page=iframes
iframe busters are intended to break a webpage out of an iframe inside another page so that they become the top level page
e.g. if I had an iframe in this answer with your site inside it, the role of an iframe buster on your site would be to bust your site out of my iframe and prevent me from using iframes to show your website
This is similar to frame busters, where a website may be encased in a frameset with a second frame up top showing a digg bar or advertisement. In this case, a frame buster would force the browser to display the website and only the website as intended by the author, rather than in a frame with potential advertisement or malware bundled in another frame.
In the provided example, the JavaScript is used to insert a script tag to a second JavaScript file which performs the actual frame busting. The JavaScript used in the html file linked simply obfuscates this process while loading different urls for different advertisements, each with different iframe html to insert.
The lengths gone to are likely to be a factor of a cat and mouse chase, as is common with frame busting techniques, where sites have written scripts to bust out of frames, and the companies responsible for framing the sites have written anti-frame busting scripts, so anti-anti-frame busting scripts have been written.
Iframe Busters are used to help certain type of rich media creatives perform their full function. FOr example an Expandable rich media will not expand if served into an Iframe without being able to bust out of the Iframe.
This is where the Iframe Buster comes into play.
The purpose of the Iframe buster is to allow the creative to break out of the Publishers Iframes so the creative can be fully functional.
Typically it s a file which needs to be placed in a folder on the sites domain.
So www.yoursitename.com/folder/iframebuster.html
This location will need to be referenced whenever you serve an Expandable ad into the Iframe.
What the iFrame Buster does is it allows an expandable banner to come outside of it's Ad Unit dimension. For rg. if you have a 300x250 ad slots and you have an 300x250 ad banner that expands to 300x500 on mouse over or on click then iFrame buster allows it break that 300x250 boundaries and give room to the banner to expand by 300x500.
Doubleclick iFrame buster us generally required if you have a Rich Media Creative like a Pushdown, PubBar or Expandable being hosted and served/setup in DART Studio.
Atlas has their own iframe buster code, MediaMind has addineyev2.html and similarly FlashTalking and other have theirs which are required to be hosted on the server where the ads are going to run.
I have a problem where I have a frameset consisting of a parent frame loaded from one domain and a contained frame from a different domain. The contained domain also sets a cookie before the frameset is loaded. However, because of the 'same orgin' policy, enforced by most browsers, a contained frame will not pass cookies if it is not from the same domain as the parent.
Unfortunately I have no control over the parent frame (or its url) and the url for the contained frame is effectively static. So the only way to pass information to the contained site is via cookies.
The only solution I have come up with is to reload the contained domain in the parent frame but this negates some of the value of using frames in the first place.
Does anyone have a better work around for this problem?
There are a couple of methods of getting around the Same Origin Policy that is preventing your iframes from speaking to each other. If you control both servers then you can use Flash's crossdomain.xml file. If you don't control one of the servers or you would like to use JavaScript, then you are forced to use a "Cross-Domain Proxy", such as this one for java or python or php.
Cross-Site XHR is another option but it isn't supported by all browsers.
There are a lot of ways to do this. Here are two that I've used:
Have both the parent and child load
a script from a common source, using
a tag. Scripts loaded in
this way don't have same-origin
issues, and the data they return
becomes part of the document object
and can interact with other scripts
loaded by the document (this is the
way that AJAST works).
Create a reverse proxy in the parent domain, and load the frame via this proxy. To the browser, it appears that they're both served from the same domain. The downside is that this can affect caching, and bypasses any content delivery network (eg, Akamai) that you might be using.
There is also a right way of doing this in HTML 5 with postMessage.
See here: http://ajaxian.com/archives/cross-window-messaging-with-html-5-postmessage
One more thought in to this, where u can use Cross Domain Messaging API to send messages from one frame to another. here is an example! Read more on this.