According to Yahoo's "Best Practices for Speeding Up your Site", the pros for using iframes:
Helps with slow third-party content like badges and ads
Download scripts in parallel
but the cons are:
Costly even if blank
Blocks page onload
I want to use an iframe to load ads using the technique mentioned on this site:
http://meanderingpassage.com/2007/08/15/keeping-javascript-widgets-from-controlling-your-blog/
Does using this technique mean that as soon as the html contents requested by the iframe are returned to the client, it will load the ad script, potentially blocking the rest of the page's rendering and downloading? Or will the iframe request get processed concurrently while rest of the document is downloaded and rendered?
I'm, however, not looking for a discussion on the philosophy of whether ads are good or bad.
I'm not quite sure why the Yahoo list says "Blocks page onload". IFrames load independently of the parent page, particularly if the iframe content is in a different domain than the main page. The "Blocks page onload" seems contradictory to the pros, both of which are due to concurrency of the iframe load.
Now, if you have an iframe that is loading something from the same domain name as the main page, that may fall into the browser's connection limit per domain, and therefore impact how quickly the main page can download its content. But if the iframe URL is a different domain, it should get its own connection limit per domain.
The biggest pro for iframes is security isolation. When you load third party script into an iframe, you don't have to worry about the third party script taking over your page and scrawling graffitti all over the place, or stealing user data from your script variables.
The biggest con for iframes is also the security isolation. ;> The brick wall that protects you from third parties also makes it very difficult to communicate / share info between parties on the same web page.
Rendering of the interior iframe is processed concurrently with the exterior page. Any javascript inside the iframe will only prevent loading of the contents inside the iframe.
Edit: also, I just noticed I answered your previous question on this subject, and as explained there it's possible to trigger iframe loading in javascript whenever you wish (e.g. after the rest of the page is loaded).
If you're putting in ads, you probably want to use AdSense (or at least test it out). The Google AdSense robot doesn't like iframes:
https://www.google.com/support/adsense/bin/answer.py?hl=en&answer=10035
Related
Why are iframes considered dangerous and a security risk? Can someone describe an example of a case where it can be used maliciously?
The IFRAME element may be a security risk if your site is embedded inside an IFRAME on hostile site. Google "clickjacking" for more details. Note that it does not matter if you use <iframe> or not. The only real protection from this attack is to add HTTP header X-Frame-Options: DENY and hope that the browser knows its job.
If anybody claims that using an <iframe> element on your site is dangerous and causes a security risk, they do not understand what <iframe> element does, or they are speaking about possibility of <iframe> related vulnerabilities in browsers. Security of <iframe src="..."> tag is equal to <img src="..." or <a href="..."> as long there are no vulnerabilities in the browser. And if there's a suitable vulnerability, it might be possible to trigger it even without using <iframe>, <img> or <a> element, so it's not worth considering for this issue.
In addition, IFRAME element may be a security risk if any page on your site contains an XSS vulnerability which can be exploited. In that case the attacker can expand the XSS attack to any page within the same domain that can be persuaded to load within an <iframe> on the page with XSS vulnerability. This is because vulnerable content from the same origin (same domain) inside <iframe> is allowed to access the parent content DOM (practically execute JavaScript in the "host" document). The only real protection methods from this attack is to add HTTP header X-Frame-Options: DENY and/or always correctly encode all user submitted data (that is, never have an XSS vulnerability on your site - easier said than done).
However, be warned that content from <iframe> can initiate top level navigation by default. That is, content within the <iframe> is allowed to automatically open a link over current page location (the new location will be visible in the address bar). The only way to avoid that is to add sandbox attribute without value allow-top-navigation. For example, <iframe sandbox="allow-forms allow-scripts" ...>. Unfortunately, sandbox also disables all plugins, always. For example, historically Youtube couldn't be sandboxed because Flash player was still required to view all Youtube content. No browser supports using plugins and disallowing top level navigation at the same time. However, unless you have some very special reasons, you cannot trust any plugins to work at all for majority of your users in 2021, so you can just use sandbox always and guard your site against forced redirects from user generated content, too. Note that this will break poorly implemented content that tries to modify document.top.location. The content in sandboxed <iframe> can still open links in new tabs so well implemented content will work just fine. Also notice that if you use <iframe sandbox="... allow-scripts allow-same-origin ..." src="blog:..."> any XSS attack within the blob: content can be extended to host document because blob: URLs always inherit the origin of their parent document. You cannot wrap unfiltered user content in blob: and render it as an <iframe> any more than you can put that content directly on your own page.
Example attack goes like this: assume that users can insert user generated content with an iframe; an <iframe> without an attribute sandbox can be used to run JS code saying document.top.location.href = ... and force a redirect to another page. If that redirect goes to a well executed phishing site and your users do not pay attention to address bar, the attacker has a good change to get your users to leak their credentials. They cannot fake the address bar but they can force the redirect and control all content that users can see after that. Leaving allow-top-navigation out of sandbox attribute value avoids this problem. However, due historical reasons, <iframe> elements do not have this limitation by default, so you'll be more vulnerable to phishing if your users can add <iframe> element without attribute sandbox.
Note that X-Frame-Options: DENY also protects from rendering performance side-channel attack that can read content cross-origin (also known as "Pixel perfect Timing Attacks").
That's the technical side of the issue. In addition, there's the issue of user interface. If you teach your users to trust that URL bar is supposed to not change when they click links (e.g. your site uses a big iframe with all the actual content), then the users will not notice anything in the future either in case of actual security vulnerability. For example, you could have an XSS vulnerability within your site that allows the attacker to load content from hostile source within your iframe. Nobody could tell the difference because the URL bar still looks identical to previous behavior (never changes) and the content "looks" valid even though it's from hostile domain requesting user credentials.
As soon as you're displaying content from another domain, you're basically trusting that domain not to serve-up malware.
There's nothing wrong with iframes per se. If you control the content of the iframe, they're perfectly safe.
I'm assuming cross-domain iFrame since presumably the risk would be lower if you controlled it yourself.
Clickjacking is a problem if your site is included as an iframe
A compromised iFrame could display malicious content (imagine the iFrame displaying a login box instead of an ad)
An included iframe can make certain JS calls like alert and prompt which could annoy your user
An included iframe can redirect via location.href (yikes, imagine a 3p frame redirecting the customer from bankofamerica.com to bankofamerica.fake.com)
Malware inside the 3p frame (java/flash/activeX) could infect your user
IFRAMEs are okay; urban legends are not.
When you "use iframes", it doesn't just mean one thing. It's a lexical ambiguity. Depending on the use case, "using iframes" may mean one of the following situations:
Someone else displays your content in an iframe
You display domeone else's content in an iframe
You display your own content in an iframe
So which of these cases can put you in risk?
1. Someone else displays your content
This case is almost always referred to as clickjacking - mimicking your site's behaviour, trying to lure your users into using a fake UI instead of the real site. The misunderstanding here is that you using or not using iframes is irrelevant, it's simply not your call - it's someone else using iframes, which you can do nothing about. Btw, even they don't need them specifically: they can copy your site any other way, stealing your html, implementing a fake site from scratch, etc.
So, ditching iframes in attempt to prevent clickjacking - it makes exactly zero sense.
2. You display someone else's content
Of the three above, this is the only one that's somewhat risky, but most of the scary articles you read all the time come from a world before same-origin policy was introduced. Right now, it's still not recommended to include just any site into your own (who knows what it will contain tomorrow?), but if it's a trusted source (accuweather, yahoo stock info etc), you can safely do it. The big no-no here is letting users (therefore, malicious users) control the src of the iframe, telling it what to display. Don't let users load arbitrary content into your page, that's the root of all evil. But it's true with or without iframes. It has nothing to do with them; it could happen using a script or a style tag (good luck living without them) - the problem is you let them out. Any output on your site containing any user-given content is RISKY. Without sanitizing (de-HTMLifying) it, you're basically opening your site up for XSS attacks, anyone can insert a <script> tag into your content, and that is bad news. Like, baaaad news.
Never output any user input without making dead sure it's harmless.
So, while iframes are innocent again, the takeaway is: don't make them display 3rd-party content unless you trust the source. In other words, don't include untrusted content in your site. (Also, don't jump in front of fast-approaching freight trains. Duuh.)
3. You display your own content in an iframe
This one is obviously harmless. Your page is trusted, the inner content of the iframe is trusted, nothing can go wrong. Iframe is no magic trick; it's just an encapsulation technique, you absolutely have the right to show a piece of your content in a sandbox. It's much like putting it inside a div or anything else, only it will have its own document environment.
TL;DR
Case 1: doesn't matter if you use iframes or not,
Case 2: not an iframe problem,
Case 3: absolutely harmless case.
Please stop believing urban legends. The truth is, iframe-s are totally safe. You could as well blame script tags for being dangerous; anything can cause trouble when maliciously inserted in a site. But how did they insert it in the first place? There must be an existing backend vulnerability if someone was able to inject html content into a site. Blaming one piece of technology for a common attack (instead of finding the real cause) is just a synonym for keeping security holes open. Find the dragon behind the fire.
Unsanitized output is bad; iframes are not.
Stop the witch-hunt.
UPDATE:
There is an attribute called sandbox, worth checking out: https://www.w3schools.com/tags/att_sandbox.asp
UPDATE 2:
Before you comment against iframes - please think about hammers. Hammers are dangerous. They also don't look very nice, they're difficult to swim with, bad for teeth, and some guy in a movie once misused a hammer causing serious injuries. Also, just googled it and tons of literature says mortals can't even move them. If this looks like a good reason to never ever use a hammer again, iframes may not be your real enemy. Sorry for going offroad.
"Dangerous" and "Security risk" are not the first things that spring to mind when people mention iframes … but they can be used in clickjacking attacks.
iframe is also vulnerable to Cross Frame Scripting:
https://www.owasp.org/index.php/Cross_Frame_Scripting
I'm displaying web pages (from other domains) in an IFrame to have navigation at the side. However, some websites have the header X-Frame-Options:deny or X-Frame-Options:sameorigin, which prevents the pages from loading in my iframe. Is there a workaround to this? How would I display the web page?
I noticed that StumbleUpon has the same issue. Here's an example with the X-Frame-Options issue: http://www.stumbleupon.com/su/53D0nJ/news.yahoo.com/worlds-dumbest-idea-taxing-solar-energy-111300623.html/
No.
It would be entirely pointless for browser vendors to provide a way for websites to say Don't let third parties put my content in a frame if they also provided a way for third parties to tell browsers to ignore that instruction.
The closest you could come would be to copy their content so it is accessible via a URL on your own server. That approach would probably cause you to run afoul of international copyright law.
I have a business web app that needs to pull in information from various other web sites. For most sites, the user just instructs the server to pull the data (either using .NET's HttpRequest, or Selenium).
But for some unfriendly, Javascript-heavy sites, our users have to visit the site manually, navigate to the right spot, and copy and paste into our application.
Other than bookmarklets, is there any way for our page to show an IFRAME with the source web site loaded, allow the user to navigate within the frame, and then capture the IFRAME's body?
Since the site in the IFRAME isn't in the same domain (not even close), I can't seem to work around browser cross-site scripting limitations. I've tried using HTML5's "sandbox" feature, but it appears to only allow communication (via "allow-same-origin") the other way, from the IFRAME to the host site, which isn't useful to me. Also, it doesn't work if the site in question attempts to load its frames to the top context.
What I'm ideally looking for is a solution that would allow the browser to be configured to trust my web site implicitly (it's an intranet app) and allow it to access any frame's contents. That would at least get me in the ballpark. Bonus points if I can get the iframe to redefine the "top" context as its own frame, so the hosted site functions properly within the frame.
The best approach I've found through many many screen scraping projects (scraping JS heavy pages) is to create a user-script or Greasemonkey script, setup a few virtual machines in their own IP space (for protection) and feed them a list of sites to visit from a remote program:
Check the queue at a set interval
Request page with Greasemonkey, etc.
Capture contents and send to remote program for processing
You can't use an iframe method and you are going to bang your head up against a wall trying to go that route, the method I've described has worked for numerous large-scale scraping projects.
I'm building a web application (a web site) which has a feature where you can embed it inside your own web site (using an iframe).
So, my app has Google Ads, and sometimes when the it is inside another site as embed (inside an iFrame) it doesn't show Ads, I mean, ads are being rendered, but sometimes that html from google is blank.
I'm concern about the Policy of GoogleAds and to not use iFrames to show ads, but I'm not using iframes to show them, my app is just inside another site as a feature.
My question is: can this be done?, or by that policy I won't be able to show ads on my embed feature?
EDIT 1
This is the content which Google is rendering (inside another iframe of another iframe):
<html>
<head>
</head>
<body style="background-color:transparent" marginwidth="0" marginheight="0">
</body>
</html>
and also, I getting an error on the console:
Blocked a frame with origin "http://googleads.g.doubleclick.net" from
accessing a frame with origin "http://example.com". Protocols,
domains, and ports must match.
where "example.com" is some site that is using my feature
EDIT 2
So, I step at the Network tab of the console, and watch what was calling. Does a GET
http://googleads.g.doubleclick.net/pagead/ads?client=ca-pub-XXXX.... With 200 OK always, but sometimes it returns just the blank HTML (posted above) and sometimes the actual html with an AD.
One more thing I didn't tell, I'm using the Asynch new Beta method, not the Synch, so I'm thinking of try the Synch and see what happens.
You might try loading the page outside an IFRAME and run network capture on the traffic to/from Google. Explore the response headers - they might be using X-Frame-Options to prevent illicit click activity on ads. There's likely very little you can do about it aside from doing a server-side request and embedding the response HTML yourself. This will dramatically slow down your page loads and might violate your ad agreement.
EDIT:
After reading your follow-up testing, it sounds more like your site just doesn't meet the criteria of enough ad campaigns to serve ads with every request. I'd look at Google's FAQs or marketing information to find out how often ads are served or why you might not be getting ads on every request. Remember, the ads are for the benefit of the advertiser and they have good tools to make sure their ads are specifically targeted to the right audience to maximize their return. Your site just might not meet enough criteria to get many ads.
EDIT 2: A quick Google search turned up this FAQ for why Ads might not be showing. They seem geared to why ads don't show at all, not intermittent appearance.
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.