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
Iframes are known for sandboxing the JavaScript inside the iframe. But, is the converse true? Do iframes protect their contents from JavaScript outside (on the hosting webpage)? My basic tests suggest that they do, but I can't find explicit documentation on this.
If you're curious, here's my use case:
A browser extension must display sensitive text on a third-party, untrusted webpage. Ideally, it will inject the text such that it cannot be accessed by JavaScript running on the untrusted webpage. The user may see it; the JavaScript may not.
The mechanisms for separating the JavaScript environments of the parent document and the iframed document work the same way in both directions.
They have their own environments
Access to the other environment is possible via parent and frameNode if they contain documents that are on the same origin
postMessage can be used to pass strings between them even if they are not on the same origin (but must be listened for by the document receiving the message).
A browser extension must display sensitive text on a third-party, untrusted webpage. Ideally, it will inject the text such that it cannot be accessed by JavaScript running on the untrusted webpage. The user may see it; the JavaScript may not.
This sounds like something better addressed using a mechanism that displays the text in the browser chrome rather than embedded in the page itself, e.g. with the Chrome popup api.
As best I can tell, the content is protected.
Iframes' contents are (by default) treated as if from a different origin. This brings the same-origin policy into play, preventing each page from accessing the others' DOM.
However, if you do <iframe sandbox="allow-same-origin">...</iframe>), then the iframe's contents can be accessed. Here's an important question:
Can malicious JavaScript programmatically set allow-same-origin to get into an iframe?
I don't know of explicit documentation on this, but my tests in Google Chrome say that programmatically changing the sandbox attribute has no effect on the iframe. Yes, you can dynamically change the sandbox attribute, but it has no effect.
This question might seem silly but I need to understand this for clarity.
According to my understanding, cross-domain problem is when the domain of the webpage which contains the IFRAME is different from the domain of the web-page opened in IFRAME.
Going by that logic, nothing should open in IFRAME ever.
When I embed a web-page "bottom:10700" in the IFRAME of my web-page "top:9700", it gives error.I am not able to see the contents in IFRAME. Error is Access denied in accessing property 'constructor'
I am getting the error while accessing the contructor (_1.contructor)
isc.A.Function=function isc_isA_Function(_1){
if(_1==null) return false;
if(isc.Browser.isIE&&typeof _1==this.$a7) return true;
var _2=_1.constructor;
if(_2&&_2.$k!=null){
if(_2.$k!=1)return false;
if(_2===Function)return true
}
This script is run when home page of bottom is opened in an iframe contained in top.
Is there any way, I can make this work. I mean can I set both the domains to be same. I don't have access to remote site's script.
Is resizing the frame after redering it once a cross-domain scenario. If not, then certainly remote site is trying to access the IFRAME element..How can I debug this??
Cross-domain issues are about the communication between iframes. You can always embed any iframe but, if domains differ, iframes cannot interact with each other e.g. execute JS, modify DOM etc.
HTML5 provides a sandbox property that re-enables particular features of the cross-domain iframe interaction. Be careful, it can be dangerous.
It is normal behavior for a page xyz.com to load in an iframe hosted on abc.com. However, you cannot change anything or access its content via code from parent abc.com.
Hope this helped.
I would like to create a web page which is a main page that has one iframe whose content does not come from the same host as the main page but I would like to know which page the user is currently browsing in the iframe.
For example, I have a main page with a button bound with an Javascript event and an iframe that load content from a site like google.
A user can navigate the content in iframe as he wants but when the button in the main page is clicked, the current url in the iframe must be popped up.
I already tried it but since the same origin policy always applies, an error like this
Permission denied to access property 'location' occurs.
I do know that it makes sense according to SOP but I really need to do it.
I would like to know if there is some hack that can do the trick or I have to admit the
restriction and design my app the other way.
If there was such a trick, it would make browser security invalid and expose privacy issues. These things are there for a reason.
You can disable this for YOURSELF, but bypassing it for others is evil.
See:
Disable same origin policy in Chrome
So I have this craptastic code that I inherited and an insane client as well. This program uses IFRAMES to emulate AJAX like calls since the previous dev could not be bothered to just do AJAX. Anyway, the problem is, is that the app calls a javascript that then sets the source of the IFRAME to some dynamic javascript.
Okay, now at the end of this javascipt, the IFRAME tries to set a value on the parent. But in IE7 and IE8 I get "Permission Denied" errors when trying to access parent.document. I imagine that this is to protect against cross domain security issues, however the parent and the child are in the same domain. The site is all https; I don't know if this makes a difference. Any ideas would be awesome.
Both the parent and the child need to be on the same domain and subdomain. Additionally, if whatever code runs in theiframe redirects the frame, it would no longer be in the correct domain when it is finished executing.