I understand that there is no way to kill the iframe breaker... However, I was wondering, is there a way to gracefully handling it.
So far, I managed to detect it before exiting, using <body onunload="function();">. I was wondering whether it is possible to prevent it from loading the iframe or force it to open in the new window, etc.
Cheers,
Mickey
In fact, you can actually do what you really want to do, which is bust the iframe buster. The technique lets you use onbeforeunload to switch the page back to yours, but indirectly, since the browsers are too smart to let you set the URL in onbeforeunload. So instead, onbeforeunload sets an indicator variable to mark that the URL has changed, and you periodically poll that variable using a setInterval routine established when your page loads. As long as you're polling fast enough to catch the variable change, you can jump in and change the page's URL yourself. The trick is to change it to a page that returns a 204, a special status which tells the browser to leave the current page alone.
That said, this is a cat-and-mouse game. Check out Jeff Attwood's StackOverflow question on this, where he asks how to bust the above technique. Web pages can bust the buster buster by beating the poll interval; basically, they set the URL to point to a tiny page, and one that has already been cached. As soon as the URL changes to that page, it will load faster than the poll routine can jump in and notice that the indicator variable has changed.
It's not easy to prevent loading the frame in the first place. If you really wanted, you could have your server download the page and parse the Javascript to see if the iframe-busting technique is present. However, short of emulating a browser, you can only rely on basic pattern-matching and it would be easy for a page to bypass that. (e.g. use top["l"+"ocation"] instead of top.location).
A smarter technique would be to track which URLs were redirecting using Ajax requests back to the server. (e.g. if the iframe is still there after it has loaded, send an Ajax request back to your server). You can't 100% guarantee the accuracy of those requests, since they come from the browser, but you can at least use them to build up a manual blacklist.
You also can't force the iframe to break out into another window.
You can use the sandbox attribute introduced in HTML5 to prevent the iframe buster. Just don't include allow-top-navigation in the whitelist:
<iframe sandbox="allow-forms allow-popups allow-pointer-lock allow-same-origin allow-scripts"
src="foo.html"></iframe>
Are you talking about an embedded iframe setting top.location? There's no way to prevent that as far as I know.
If you're worried about the contents of an iframe doing something you don't want, you could consider sanitizing the contents of that frame and hosting it yourself. Obviously this is very tricky, but it's pretty much the only true solution. See Caja for a project that does this. This limits what you can actually host of course (if the code you're hosting uses XHR you're outta luck, for instance).
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
Is it possible to get around the security and mimick either a full-browser or mobile browser within a webpage?
I had an idea to set the HTML manually, using an AJAX/XMLHttpRequest ("Get" request)
document.querySelector('#myiframe').contentWindow.document.write("<html><body>Hello
world</body></html>");
(from How to set HTML content into an iframe)
Can anyone verify this is possible? I'm guessing you would lose relevant site date (cookies, cache, etc)
Is it possible to get around the security
Yes, many browsers let you start them in a security-off mode, e.g. on chrome you run the program with the --disable-web-security flag. However, you should never ask a client to do this.
An alternative way would be to write a Java applet, or some other third-party plugin, which fetches the resources you want and then passes it over to the browser with your favourite method, from which you can use JavaScript on the data as desired. This method would lose things like cookies, and might be exploitable so I wouldn't recommend it.
mimick either a full-browser or mobile browser within a webpage?
Finally, if you don't mind the "URL bar" displaying the wrong thing when a user navigates, you could just use the default behaviour. This method is totally acceptable and doesn't circumvent any security.
I want my webpage to have two parts. The top part has a textbox. When the user types a URL into the textbox, the bottom part browses to the content of that URL. When the user clicks a link within the bottom part, the bottom part navigates to the new URL, and the textbox in the top part changes to the new URL. How can I do it?
NOTE: This behavior is the same as in Google Translate (e.g. here), but without any translation.
first problem..
Same origin issue
The only way to achieve what you are asking is exactly the way google translate does what it does - which is to use a server-side powered script as a proxy request:
http://translate.google.com/translate_un?depth=1&hl=en&ie=UTF8&prev=_t&rurl=translate.google.com&sl=auto&tl=en&twu=1&u=http://de.wikipedia.org/wiki/USA&lang=de&usg=ALkJrhgoLkbUGvOPUCHoNZIkVcMQpXhxZg
The above is the URL taken from the iframe that Google translate uses to display the translated page. The main thing to note is that the domain part of the URL is the same as the parent page's URL http://translate.google.com -- if both your frame and your parent window do not share the same domain, then your parent window's JavaScript wont be able to access anything within the iframe. It will be blocked by your browser's in-built security.
Obviously the above wont be a problem if in your project you are only ever going to be navigating your own pages (on the same domain), but considering you are proffering Google Translate as an example I'm assuming not.
What would Google do?
What the above URL does is to ask the server-side to fetch the wikipedia page and return it so that the iframe can display it - but to the iframe this page appears to be hosted on translate.google.com rather than wikipedia. This means that the iframe stays within the same origin as the parent window, and means that JavaScript can be used to edit or modify the page within the iframe.
next problem....
Rewrite the proxied content
Basically what I'm saying is that this can't be achieved with just HTML and client-side JavaScript - you need to have something to help from the server-side i.e. PHP, Python, Ruby, Lisp, Node.. and so on. This script will be responsible for making sure the proxied page appears/renders correctly e.g. you will have to make sure relative links to content/images/css on the original server are not broken (you can use the base tag or physically rewrite relative links). There are also many sites that would see this as an illegal use of their site, as per their site's terms of use and so should be black listed from your service.
final problem..?
Prevent the user from breaking away from your proxy
Once you have your proxy script, you can then use an iframe (please avoid using old framesets), and a bit of JavaScript magic that onload or ondomready of the iframe rewrites all of the links, forms and buttons in the page. This is so that when clicked or submitted, they post to your proxy script rather than the original destination. This rewrite code would also have to send the original destination to your proxy script some how - like u in the Google translate URL. Once you've sorted this, it will mean your iframe will reload with the new destination content, but - all importantly - your iframe will stay on the same domain.
too many problems!
If it were me, personally, I'd rethink your strategy
Overall this is not a simple task, and it isn't 100% fullproof either because there are many things that will cause problems:
Certain sites are designed to break out of frames.
There are ways a user can navigate from a page that can not be easily rewritten i.e. any navigation powered by JavaScript.
Certain pages are designed to break when served up from the wrong host.
Sites that do this kind of 'proxying' of other websites can get into hot water with regards to copyright and usage.
The reason why Google can do it is because they have a lot of time, money and resources... oh and a great deal of what Google translate does is actually handled on the server-side - not in JavaScript.
suggestions
If you are looking for tracking users navigating through your own site:
Use Google Analytics.
Or implement a simple server-side tracking system using cookies.
If you are looking to track users coming to your site and then travelling on to the rest of the world wide web:
Give up, web technologies are designed to prevent things like this.
Or join an online marketing company, they do their best to get around the prevention of things like this.
add a javascript function to your second frame -
<frame id="dataframe" src="frame_a.htm" onload="load()">
let the text box have an id - say "test"
function load()
{
document.getElementById('test').value=document.getElementById('dataframe').src
}
While I'm learning about iframe i found some of the URLs cannot be loaded into iframe. While i tried to load them they replace the current page with that iframe URL page. My friend suggested me to use an iframe enforcer but he is not sure about it.
What I'm wondering is, if it is possible to enforce every url into iframe. If yes which is the best way to do so. Also if this is possible to block our site to load on any iframe. I'm so eager to learn about this.
One of the URL that is not loading is www.dinamalar.com
This is not possible, you cannot load a website into a frame if it doesn't cooperate. Even if JavaScript is off, most browsers already support the X-Frame-Options response header. This is actually a security feature because a malicious website could load a trusted website into a frame and trick the user into clicking a link in it to start some action (Clickjacking).
That said, I think that MSIE's security="restricted" attribute prevents frames from breaking out using JavaScript code the way dinamalar.com does it. I don't think that any browser other than MSIE implements this however (and they don't plan to either).
Getting directly the current iframe's URL, in javascript, is not possible due to security restriction.
Is there a way to override this restriction?
Using ActiveX control?
Changing the browser's security options?
Using HTML5?
Using flash?
Using server side scripting?
Getting directly the current iframe's URL, in javascript, is not possible due to security restriction
If you mean cross-domain IFrames, and you have no way of controlling the inlying page, then this is correct.
As far as I know, no, there is no way to get around this.
The only way I can think of - and you don't want to go down that road - is proxying every page inside the iframe through a local server script, rewriting every link and action within each page to go through the proxy, too. But that is hugely difficult, comes with a shitload of things to be aware of, and is not a real option - many modern sites will simply break if proxied that way.
As I understand it if you have no control of the frame you are not supposed to know what is going on in this frame. So, knowing it would be a security bug and should be fixed. Browsers are designed to not allow the page spy on what you are doing in another page.
If you have control over iFrame there are some options for you
There is a discussion here:
How do I get the current location of an iframe?
basically
var iframe = document.getElementById('loader').src
You can actually get the location if iframe is located at the same server. If it is located at a different server the only way to go is to rewrite URLs like some sites do. It is not easy to do though
You can also do HTML5 cross-window communication:
http://ajaxian.com/archives/cross-window-messaging-with-html-5-postmessage