What are the application security risks of including a hidden 3rd Party iFrame?
If I understand correctly...
Click jacking isn't an issue for me because I own the parent page
Same-Origin Policy prevents 3p frame from interacting my dom/cookies/js
The frame is hidden, so I don't have to worry about anything that may be displayed in the frame
However I did some experiments in the Chrome console and...
3p frame can call things like alert/prompt
3p frame can redirect the parent via location.href
Malware inside the 3p frame (java/flash/activeX) could infect my user
I'd love to see a list of the possible issues and any mitigations, but I can't find a good source of information.
So...What are the application security risks of including a hidden 3rd Party iFrame?
If you are implementing Iframes on your website, you could use the sandbox tag in HTML5' iframe to prevent yourself/others on your website.
Source: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox
I don't know how effective it is (the sandbox feature), but it states it can restrict scripts, forms etc inside the iframe.
<iframe sandbox="" src="www.example.com"/>
Although not a guaranteed and effective method, it's one of many different ways. On your end though, you could use add-ons such as NoScript to prevent certain/all scripts from running.
It's possible that the 3rd party iframe, as you said, could use exploits such as drive-by-downloads, browser exploits to gain access to your OS and possibly more.
See also here: Why are iframes considered dangerous and a security risk?
Hope this helps.
Related
In our web app/site, I need to use an iframe or a popup window to validate if the current token is valid and refresh it if no.
So, I create an iframe, and set the property 'src' to the validation link such as "https://<domain_name>/auth?client_id=xxx" which is different to our app domain https://<app_domain>. and the return value will like "https://<domain_name>/code=yyyy"
document.createElement('iframe');
and I added the message handle for the web app/site, like
window.addEventListener("message", this.messageHandler);
in the messageHandler, I will check if the message is from a specified website, and then validate the "code" value, blabla, etc.
But when running in Chrome, I always got the error
"Blocked autofocusing on a element in a cross-origin subframe."
what confused me is:
it always failed when running in the Chrome browser, but it can work fine in Firefox and Edge chromium.
I tried to set iframe.sandbox = "allow-forms allow-scripts allow-same-origin", the problem still existed.
If the validating token failed in iframe or timeout, I will create a popup window to continue validating and refresh the token. But every time, using popup window can always succeed. If it is really a cross-origin issue, why using iframe failed but using popup window succeeded.
I didn't use window.postmessage. because I don't know how to pass the return value of iframe/popup-window to the main page.
I used CORS extension of Chrome or using parameter --disable-web-security when launching Chrome. the problem still existed.
when I created the iframe or popup window. it is very simple, I just set the iframe.src property, there is no element being created.
any help will be much appreciated.
p.s.
I refer to the following doc:
Blocked autofocusing on a form control in a cross-origin subframe
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
Support for iframes in web development will only get worse over time as they are a security black hole, browsers are gradually over time locking out features and use of them.
I am assuming you are doing this because you are validating a user on a third party service, validating by watching the response of a third party service website?
Without knowing the service you are using I cannot comment specifically but for anyone looking to do something similar I would highly suggest not doing this:
As mentioned, iframes are constantly having features locked down due to security concerns
An attacker could change the source of the iframe and submit their own iframe to look like it has been correctly validated
It's unlikely that the page you are using as your iframe src is intended for this use, which will come back and bite you when the 3rd party developer changes how their page behaves, which they likely will do without knowing it's going to break your application
I recommend:
Finding a stable API the 3rd party service offers and using that
Finding another service if none exist
Apologies to rain on your parade!
I disagree that iframes are a security risk, rather they can be if not implemented properly.
How to implement them properly should be asked in another question and probably starting with a carefully implemented Content Security Policy as a priority.
I also use iframes within a Chrome extension that has to pass rigorous Google security.
As for the question, I've noticed that error too and I am focusing on an input box when the iframe is loaded and the focus works! I put it down to being a Chrome bug as the warning suggests it has stopped auto focusing when it hasn't.
As for the un-related point about passing the value back to the parent holding the iframe, I can help you with that, but you should ask it in a new question.
Disable some feature of browser setting
Browser Changes
chrome://flags/#cookies-without-same-site-must-be-secure
chrome://flags/#same-site-by-default-cookies
chrome://flags/#enable-removing-all-third-party-cookies
Above URL just paste it and disabled it. Then ok and relaunch the browser.
Then done it.
I have a website that have a foreign iframe. There are multiple third party scripts that run inside this foreign iframe.
I know that if I will prefetch these scripts from the main window - the iframe will need to reload these sources (as the prefetch was done in a different domain).
What can be the reason that if I add dns-prefetch or preconnect resource hints for the third party scripts in the main window, the performance of loading these scripts in the iframe will be improved? Is this just because I warm-up the scripts?
Some browsers implement a double-keyed HTTP Cache for privacy reasons to prevent tracking. This means if domain1 loads jQuery from a CDN and then domain2 loads the same jQuery resource from the same domain it will be downloaded again rather than reusing the same copy from the HTTP cache.
Safari has done this for a while and Chrome have recently stated they will do the same.
This means you can’t prefetch or preload resources and scripts in foreign domain iframes as you state.
dns-prefetch and preconnect have no such privacy implications (for now - see Andy's answer below for potential upcoming changes for preconnect). so they can be used to improve performance in iframes by front loading some of the work to get these scripts (though it should be noted that browsers may not always use the same connection depending on the browser which may impact use of preconnect).
It's likely that connection pools are also going to become double keyed too –https://github.com/whatwg/fetch/issues/917
In this scenario dns-prefetch will be ok, but a preconnect from the top frame origin for resources referenced in the iframe won't as top frame origin will be different to the iframe origin
Contents of the iframe should still be able to make their own preconnects though – using either link element or HTTP header
(Added as new answer as comments can't have line breaks)
I want to redirect my website from iframe to main url, here is my code:
window.setTimeout(function() {
window.top.location = jQuery("link[rel=canonical]").attr("href") + "#ref=shahrekhabar";
return false;
}, 100);
It works on Firefox but Google Chrome blocked this type of redirecttion.
I try with window.top.location.href and window.top.location.replace and window.top.location.assign but no luck.
The reason:
Some spam sites shows my site in iframe and I want to escape from them and I think redirection is good solution.
Edit to answer the TRUE question:
A common issue with stack overflow is that users will often ask how to do something they think solves the problem they are encountering, rather than just asking us how to solve the problem. We always appreciate hearing how you've gone about trying to solve your problem, but it's always best if we know that and what the root problem is. So in your case, given your comment on my answer, the question should have been:
Currently my website is being shown in iframes on sites that I have no control over? I'd like to prevent them from doing this, how can I do so? I'm currently trying to redirect my website from iframe to main url, but it won't work on Chrome. ... Rest of question ...
Given this question, my original answer is useless as:
You still can't and shouldn't be able to alter the URL of the parent window.
You don't own the sites showing your page in the iframe, which means you can't register a listener to handle the postMessage or CustomEvent.
Funny enough, what you're trying to do is the exact reason why chrome doesn't let you do it hahaha. But don't worry there is still a solution.
Introducing CORS!
CORS or Cross Origin Resource Sharing is the name for when a site on one domain accesses resources that aren't on the same domain. Doesn't matter who owns either site, if the two domains are different it's CORS. Now this is good for you because there are such things as CORS policies where you can prevent anyone from even accessing a resource on your domain if they make a CORS request. Keep in mind this will mean you can't display your site within an iframe on another one of your sites unless they're on the same domain, but it sounds like it may be worth it for you.
In case you're curious, unlike what you're trying to do, using CORS policy is very much standard procedure for developers that don't wish for their sites to appear in iframes and is in fact used by famous sites such as facebook, google, and even good ole stackoverflow (I would know, I tried to make a way to view multiple questions at the same time via iframes a while back). I've included an example below that shows this all to be true, alongside an example of a site that doesn't care (editpad.org). In order to implement this on your site check out this link.
<iframe src="https://www.editpad.org/"> </iframe>
<iframe src="https://www.google.com/"> </iframe>
<iframe src="https://www.facebook.com/"> </iframe>
<iframe src="https://stackoverflow.com/posts/53917955"> </iframe>
The old answer:
So you're trying to change the location of the parent window from an iframe? This sounds extremely dangerous and the fact that Firefox doesn't block it worries me. Good job Chrome!
Why wouldn't you want this?
I can think of a few reasons you wouldn't want this, but the biggest is that it's just poor programming. A page should work completely independent of whether or not it is inside an iframe, and even if the page should only be viewed in an iframe it still shouldn't be interacting with the parent window in such a direct way.
Possible issues that could arise if this were allowed on all platforms:
Include an iframe in your ads and as soon as your ad is displayed, redirect the user to your site or worse, redirect them to a mirror of the current site that you're hosting to collect passwords / personal information.
If you can mess with the windows location (arguably the most important and static thing about a web page being viewed) why can't you mess with anything? Can you go into the parent window and adjust the DOM or do a query selection for inputs of type password in order to copy the values? Or what about attaching event listeners to the parent window silently such that you can log any and all key presses.
How can you work around it?
Don't worry too much about the issues I brought up above, as they can all be avoided by following proper standards. In fact, the JavaScript devs envisioned this exact problem which is why you can post messages across windows. Look into this link and go from there, feel free to comment if you have any questions but it should be as simple as posting a message, detecting it on the parent window, and then changing the location as you wish.
If you need to send data from the iframe to the parent window, or your iframe isn't hosted on the same domain, you can instead use CustomEvents (which I prefer even when my iframe is on the same domain) which allow you to attach a data object.
As for why either of these two solutions is better than directly manipulating the parent window, it's all due to the parent window needing to register a listener for the message / custom event. If your page is not inside an iframe it'll simply post a message to itself which it won't be listening for. If your page is inside an iframe on the page it should be on, your parent page should already have registered the proper listeners. And there is no chance for malicious use of these features because again, I have to register a listener and I choose what is done with the event once it's caught.
I'd like to use social sharing widgets (e.g. Facebook Like, Twitter Tweet, etc) on my site, but I don't want to directly embed third-party script tags. I'd like my site to only run either trusted or sandboxed code.
Google Caja might work, but it requires the third-party code be written specifically to accommodate Caja.
Content Security Policy might work, but it is sparsely implemented, especially with IE (even 10) and there's no good way to detect if it's even present.
Is there a solution to this? Or do I have to choose between not having the buttons at all and running untrusted JavaScript?
Additional context: I'd like to run my entire site on HTTPS, but I also want to have sharing buttons. I don't want to potentially leak secure cookies to Facebook or Twitter.
If you don't trust third-party JavaScript (and I don't blame you, it's scary!), your best bet is to use the iframe implementations that these social networks provide. For instance, you can include a Facebook "Like" button by adding the following frame to your site:
<iframe src="//www.facebook.com/plugins/like.php?href=[PAGE_URL_GOES_HERE]&send=false&layout=button_count&width=450&show_faces=true&font&colorscheme=light&action=like&height=21" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:450px; height:21px;" allowTransparency="true"></iframe>
https://dev.twitter.com/docs/tweet-button#using-an-iframe has details on a similar setup for Twitter.
Encapsulating the code in an iframe gives you some measure of protection against the content of the frame, as it can't reach up into the parent to grab data or manipulate your code.
You can increase the level of protection by sandboxing the iframe via the (cleverly named) sandbox attribute. For instance:
<iframe sandbox="allow-script allow-same-origin" src="..."></iframe>
would load a page into an iframe, and allow it to run script with access to its origin (but still not the parent's origin). It would not, however, be able to navigate the top level document, load plugins, etc. Sandboxing is supported in Chrome, Safari, Firefox 18+, and IE9 (I think. Might be 10.).
I don't want to potentially leak secure cookies to Facebook or Twitter.
If you are afraid that when browser will go and fetch twitter/facebok JS it will pass on your website cookies, then it won't. But if you included some js it can access cookies by document.cookies. Moreover I don't think that rewriting is really an option, too much work, and what if it changes?
Security vs. usability was always a battle. I would recoomend not including those buttons on sites with sensitive informations on it. And just pray for nothing bad to happen :) Plus you may add adiitional protection mechanisms like requesting to reauthenticate before any change to user data or any sensitive data.
Certain websites like Twitter, Flickr, etc avoid being stuck within an iframe. Is there any way to stop this from happening? I just need to see the public data so I am open to disabling Javascript, etc. How do I disable Javascript running on the iframe? Is this possible?
You can't disable JavaScript on iFrames or any other resources AFAIK.
The only way to reliably do this is to load the sites through a proxy PHP or other server-side script, filter out any JavaScript (which will break many sites), and fix all relative references to images and other media - a task that would take an insane amount of time to complete if you want the sites to actually work.
If you just need some data from the sites, proxying might work. Seeing as the Same Origin Policy would prevent you getting anything from an IFRAME from a different domain anyway, it is also the only way to access content on those sites using JavaScript.
In IE only, there is the <iframe security="restricted"> attribute. This disables JavaScript in the targeted document, which would break a JS frame-escape script — along with all other interaction that's script-dependent.
However, apart from the browser compatibility issue, it's very rude to frame a site that doesn't want to be framed, and it will work less and less anyway as more sites deploy X-Frame-Options.
I'm not sure what you mean by “need to see the public data”... as Pekka said, you won't be able to ‘see’ into an iframe's DOM from outside it, as that would be a security problem.