isInIframe Detection in Javascript - javascript

Javascript:
inFrame = true;
try {
if(window.top == self) {
inFrame = false;
}
} catch (err){}
try {
if(window.parent.location == self.location){
inFrame = false;
}
} catch (err){}
This is a piece of javascript code I use to detect whether my library is inside an iframe.
1 out of 100% of requests report that my library is inside an iframe which I think is not possible.
Is there a possibility that this code to fail [report true on false or vice versa]?
From access log [I log every such iframe requests]
I found that it happens in all modern browsers [ie 6-9, chrome, ff, safari] from user agent string.
I couldn't make any sense out of referrer because they are same as my publisher site.
In some cases I found for same referrer, same url requested & same client ip my library had been once inside an iframe & not in other. This made me doubt the above code.
Will there be any difference while window or document is being loaded in the properties [self, location, top, parent] I use to check? Because my script loads and executes synchronously mostly before the document is ready or window is completely loaded and that does the iniframe test to proceed further.

this is how I get the is in frame result and it works for me inFrame = window.top != window

If all you're trying to do is detect when your code is in a frame of any kind, all you need is this:
if (window.top !== window) {
// you are embedded in a frame
}
or to set your variable inFrame like this:
inFrame = (window.top !== window);
or in function form:
function isInFrame() {
return (window.top !== window);
}
As long as you aren't accessing properties on the window.top object, you shouldn't need exception handlers to protect from cross domain parents. In a cross-origin situation, you can access window.top, but you cannot access properties such as window.top.location.href.
As for your other questions:
Is there a possibility that this code to fail [report true on false or vice versa]?
The first part of your code looks OK though the exception handler is not required. The second part of your code will throw an exception every time in modern browsers when the window and parent frame are different origins.
Will there be any difference while window or document is being loaded
in the properties [self, location, top, parent] I use to check?
Because my script loads and executes synchronously mostly before the
document is ready or window is completely loaded and that does the
iniframe test to proceed further.
At the point your window is loading, it is safe to make this check. Both window and window.top will be valid at that point even if neither has completed loading yet. So, there should not be any issues with inFrame detection that require you to wait for anything to complete loading.

You know most modern browsers allow you to "View Frame" right? As in, view the frame content without the parent. That's an entirely plausable answer for 3. (I do it all the time).
A plausible cause of 1 and 2 is that self is not really defined in javascript therefore may not always be equal to window. You should therefore be checking window or better yet window.self not self like Özgür suggests.

Related

Is there a way to prevent an iframe sandbox from sending postMessages?

Let's say I have an Iframe with the attribute sandbox="allow-scripts".
I might or might not be in control of the page loading that iframe.
Is there any possibility how to prevent the iframe from sending postMessages other than overwriting the parents postMessage function - which I might not be able to do if the parent is not my domain.
A colleague came up with an idea. One can sum it up with: make the parent part of your domain so that you can overwrite its postMessage method.
If it is not possible to control the top window containing the iframe, why not put the original iframe within another iframe. The additional frame-layer can act as a firewall. By overwriting the postMessage-Method of that intermediate firewall-iframe one can make sure that the original iframe can postMessage whatever it wants but the firewall-iframe only forwards incomming messages that are wished to be postable.
Of course this comes with some constraints as to what has to be the destination domain of the postMessage-call.
You should probably just check the read-only source property of the MessageEvent.
<iframe src="evil.html" class="ignore-messages"></iframe>
<iframe src="safe.html"></iframe>
window.addEventListener('message', function(e)
{
// Blacklist messages if e.source matches iframe.ignore-messages
if(Array.from(document.querySelector('iframe.ignore-messages'))
.map(f => f.contentWindow)
.indexOf(e.source) !== -1
) return;
// handle message from safe.html
// this message cannot come from evil.html,
// since that iframe has the class "ignore-messages"
};
Other ways to achieve this are through a whitelist such as:
// allow only from parent
if(e.source !== parent) return;
// allow only from a given set of iframes
if(Array.from(document.querySelectorAll('iframe.accept-messages')).map(f => f.contentWindow).indexOf(e.source) === -1) return;
The advantage of a whitelist over a blacklist, is that the iframe which sent a message may not be in the DOM-tree anymore, or the classList may have been changed, etc. Which is more common when working with dynamic HTML generated by javascript. Therefore, using a whitelist is a foolproof approach.

How to determine if JS code executes in iframe? [duplicate]

I am writing an iframe based facebook app. Now I want to use the same html page to render the normal website as well as the canvas page within facebook. I want to know if I can determine whether the page has been loaded inside the iframe or directly in the browser?
Browsers can block access to window.top due to same origin policy. IE bugs also take place. Here's the working code:
function inIframe () {
try {
return window.self !== window.top;
} catch (e) {
return true;
}
}
top and self are both window objects (along with parent), so you're seeing if your window is the top window.
When in an iframe on the same origin as the parent, the window.frameElement method returns the element (e.g. iframe or object) in which the window is embedded. Otherwise, if browsing in a top-level context, or if the parent and the child frame have different origins, it will evaluate to null.
window.frameElement
? 'embedded in iframe or object'
: 'not embedded or cross-origin'
This is an HTML Standard with basic support in all modern browsers.
if ( window !== window.parent )
{
// The page is in an iframe
}
else
{
// The page is not in an iframe
}
I'm not sure how this example works for older Web browsers but I use this for IE, Firefox and Chrome without an issue:
var iFrameDetection = (window === window.parent) ? false : true;
RoBorg is correct, but I wanted to add a side note.
In IE7/IE8 when Microsoft added Tabs to their browser they broke one thing that will cause havoc with your JS if you are not careful.
Imagine this page layout:
MainPage.html
IframedPage1.html (named "foo")
IframedPage2.html (named "bar")
IframedPage3.html (named "baz")
Now in frame "baz" you click a link (no target, loads in the "baz" frame) it works fine.
If the page that gets loaded, lets call it special.html, uses JS to check if "it" has a parent frame named "bar" it will return true (expected).
Now lets say that the special.html page when it loads, checks the parent frame (for existence and its name, and if it is "bar" it reloads itself in the bar frame. e.g.
if(window.parent && window.parent.name == 'bar'){
window.parent.location = self.location;
}
So far so good. Now comes the bug.
Lets say instead of clicking on the original link like normal, and loading the special.html page in the "baz" frame, you middle-clicked it or chose to open it in a new Tab.
When that new tab loads (with no parent frames at all!) IE will enter an endless loop of page loading! because IE "copies over" the frame structure in JavaScript such that the new tab DOES have a parent, and that parent HAS the name "bar".
The good news, is that checking:
if(self == top){
//this returns true!
}
in that new tab does return true, and thus you can test for this odd condition.
The accepted answer didn't work for me inside the content script of a Firefox 6.0 Extension (Addon-SDK 1.0): Firefox executes the content script in each: the top-level window and in all iframes.
Inside the content script I get the following results:
(window !== window.top) : false
(window.self !== window.top) : true
The strange thing about this output is that it's always the same regardless whether the code is run inside an iframe or the top-level window.
On the other hand Google Chrome seems to execute my content script only once within the top-level window, so the above wouldn't work at all.
What finally worked for me in a content script in both browsers is this:
console.log(window.frames.length + ':' + parent.frames.length);
Without iframes this prints 0:0, in a top-level window containing one frame it prints 1:1, and in the only iframe of a document it prints 0:1.
This allows my extension to determine in both browsers if there are any iframes present, and additionally in Firefox if it is run inside one of the iframes.
I'm using this:
var isIframe = (self.frameElement && (self.frameElement+"").indexOf("HTMLIFrameElement") > -1);
Use this javascript function as an example on how to accomplish this.
function isNoIframeOrIframeInMyHost() {
// Validation: it must be loaded as the top page, or if it is loaded in an iframe
// then it must be embedded in my own domain.
// Info: IF top.location.href is not accessible THEN it is embedded in an iframe
// and the domains are different.
var myresult = true;
try {
var tophref = top.location.href;
var tophostname = top.location.hostname.toString();
var myhref = location.href;
if (tophref === myhref) {
myresult = true;
} else if (tophostname !== "www.yourdomain.com") {
myresult = false;
}
} catch (error) {
// error is a permission error that top.location.href is not accessible
// (which means parent domain <> iframe domain)!
myresult = false;
}
return myresult;
}
Best-for-now Legacy Browser Frame Breaking Script
The other solutions did not worked for me. This one works on all browsers:
One way to defend against clickjacking is to include a "frame-breaker" script in each page that should not be framed. The following methodology will prevent a webpage from being framed even in legacy browsers, that do not support the X-Frame-Options-Header.
In the document HEAD element, add the following:
<style id="antiClickjack">body{display:none !important;}</style>
First apply an ID to the style element itself:
<script type="text/javascript">
if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}
</script>
This way, everything can be in the document HEAD and you only need one method/taglib in your API.
Reference: https://www.codemagi.com/blog/post/194
I actually used to check window.parent and it worked for me, but lately window is a cyclic object and always has a parent key, iframe or no iframe.
As the comments suggest hard comparing with window.parent works. Not sure if this will work if iframe is exactly the same webpage as parent.
window === window.parent;
Since you are asking in the context of a facebook app, you might want to consider detecting this at the server when the initial request is made. Facebook will pass along a bunch of querystring data including the fb_sig_user key if it is called from an iframe.
Since you probably need to check and use this data anyway in your app, use it to determine the the appropriate context to render.
function amiLoadedInIFrame() {
try {
// Introduce a new propery in window.top
window.top.dummyAttribute = true;
// If window.dummyAttribute is there.. then window and window.top are same intances
return !window.dummyAttribute;
} catch(e) {
// Exception will be raised when the top is in different domain
return true;
}
}
Following on what #magnoz was saying, here is a code implementation of his answer.
constructor() {
let windowLen = window.frames.length;
let parentLen = parent.frames.length;
if (windowLen == 0 && parentLen >= 1) {
this.isInIframe = true
console.log('Is in Iframe!')
} else {
console.log('Is in main window!')
}
}
It's an ancient piece of code that I've used a few times:
if (parent.location.href == self.location.href) {
window.location.href = 'https://www.facebook.com/pagename?v=app_1357902468';
}
If you want to know if the user is accessing your app from facebook page tab or canvas check for the Signed Request. If you don't get it, probably the user is not accessing from facebook.
To make sure confirm the signed_request fields structure and fields content.
With the php-sdk you can get the Signed Request like this:
$signed_request = $facebook->getSignedRequest();
You can read more about Signed Request here:
https://developers.facebook.com/docs/reference/php/facebook-getSignedRequest/
and here:
https://developers.facebook.com/docs/reference/login/signed-request/
This ended being the simplest solution for me.
<p id="demofsdfsdfs"></p>
<script>
if(window.self !== window.top) {
//run this code if in an iframe
document.getElementById("demofsdfsdfs").innerHTML = "in frame";
}else{
//run code if not in an iframe
document.getElementById("demofsdfsdfs").innerHTML = "no frame";
}
</script>
if (window.frames.length != parent.frames.length) { page loaded in iframe }
But only if number of iframes differs in your page and page who are loading you in iframe. Make no iframe in your page to have 100% guarantee of result of this code
Write this javascript in each page
if (self == top)
{ window.location = "Home.aspx"; }
Then it will automatically redirects to home page.

Check if window parent is same domain

My problem is that I'm creating an application that will be added to different pages in an iframe. But sometimes it will be on my own domain and sometimes on some one elses.
And when it is hosted on my own domain I want to be able to call functions outside the frame.
Is it possible to check if the parent window is on the same domain (with javascript/jQuery)?
At the moment I get this ugly error when trying to access somethin outside my frame when not hosted on my own site:
"Error: Permission denied to access property 'document'"
Wanna do something like this:
if(window.parent is accessible) {
// Do special stuff
} else {
// Do nothing
}
You could use:
try{
parent.document;
// accessible
}catch(e){
// not accessible
}
I tried checking parent document, but for some reasons in new iOS devices (chrome or safari) it didn't throw the exception, but just continued to the next step.
So I took it another step:
try{
var doc = parent.document;
if(!doc)
throw new Error('Unaccessible');
// accessible
}catch(e){
// not accessible
}

Frame breaking only cross-domain but not for iframes from the same origin?

This question was previously asked and answered correctly, but there did not seem to be a solution posted.
If a site has iframes, and one wants to prevent those from being enclosed in a frame from a different domain, simplistic frame-busting will not be useful:
<script>if (top != self) top.location = location</script>
However, since cross-frame scripting to other domains should generate exceptions, something like this seems to work well inside the iframe:
<script>
try {
if (window.document.domain != top.document.domain) { // throws exception
throw "You naughty puppy!"; // Should not ever get here, right?
}
}
catch () {
top.location = "/error/naughtypuppy";
}
</script>
The if above should be enough on its own to prevent cross-domain framing of iframes. It should only ever return false or throw an exception, so is there anyway the script could reach the throw statement in a browser?
Would this be sufficient to prevent framing only from other domains?
<script>
try {
var bogus = top.document.domain;
}
catch () {
top.location = "/error/naughtypuppy";
}
</script>
Edit: A similar solution is hinted at here, but one would not rely on the parent frame to include the frame-busting code. Detect when iframe is cross-domain, then bust out of it . Essentially the same solution as "try to access the other frame and bust if an exception occurs."
That code is vulnerable to a form of attack that leverages the "onbeforeunload" feature. The parent (evil) page sets up a interval handler (which is invulnerable to your code, due to the domain difference) and an "onbeforeunload" handler. The second handler just updates some global variable (also invulnerable) to record the fact that the window is "under attack", and then the interval timer (running fast enough that it should be able to become active before the browser has completed the outer window update to your legit URL) pops up and updates window.location to point to some attacker-controlled URL that returns a no-op 204 response. The browser forgets about your HTTP request and "updates" the window from that newer transaction instigated by the interval handler instead.
Here's the older SO question: Frame Buster Buster ... buster code needed
I have a site that still has frames and I can't remove them for now. This was the best solution I was able to find:
<style>html { display:none }</style>
<script>
if (self == top) {
document.documentElement.style.display = 'block';
} else {
top.location = self.location;
}
</script>
From this link: XFS 101-cross-frame-scripting-explained
Based on a presentation from: OWASP_AppSec_Research_2010_Busting_Frame_Busting_by_Rydstedt
Here is a more updated OWasp Clickjacking page

Detect failure to load contents of an iframe

I can detect when the content of an iframe has loaded using the load event. Unfortunately, for my purposes, there are two problems with this:
If there is an error loading the page (404/500, etc), the load event is never fired.
If some images or other dependencies failed to load, the load event is fired as usual.
Is there some way I can reliably determine if either of the above errors occurred?
I'm writing a semi-web semi-desktop application based on Mozilla/XULRunner, so solutions that only work in Mozilla are welcome.
If you have control over the iframe page (and the pages are on the same domain name), a strategy could be as follows:
In the parent document, initialize a variable var iFrameLoaded = false;
When the iframe document is loaded, set this variable in the parent to true calling from the iframe document a parent's function (setIFrameLoaded(); for example).
check the iFrameLoaded flag using the timer object (set the timer to your preferred timeout limit) - if the flag is still false you can tell that the iframe was not regularly loaded.
I hope this helps.
This is a very late answer, but I will leave it to someone who needs it.
Task: load iframe cross-origin content, emit onLoaded on success and onError on load error.
This is the most cross browsers origin independent solution I could develop. But first of all I will briefly tell about other approaches I had and why they are bad.
1. iframe That was a little shock for me, that iframe only has onload event and it is called on load and on error, no way to know it is error or not.
2. performance.getEntriesByType('resource'). This method returns loaded resources. Sounds like what we need. But what a shame, firefox always adds Resource in resources array no matter it is loaded or failed. No way to know by Resource instance was it success. As usual. By the way, this method does not work in ios<11.
3. script I tried to load html using <script> tag. Emits onload and onerror correctly, sadly, only in Chrome.
And when I was ready to give up, my elder collegue told me about html4 tag <object>. It is like <iframe> tag except it has fallbacks when content is not loaded. That sounds like what we are need! Sadly it is not as easy as it sounds.
CODE SECTION
var obj = document.createElement('object');
// we need to specify a callback (i will mention why later)
obj.innerHTML = '<div style="height:5px"><div/>'; // fallback
obj.style.display = 'block'; // so height=5px will work
obj.style.visibility = 'hidden'; // to hide before loaded
obj.data = src;
After this we can set some attributes to <object> like we'd wanted to do with iframe. The only difference, we should use <params>, not attributes, but their names and values are identical.
for (var prop in params) {
if (params.hasOwnProperty(prop)) {
var param = document.createElement('param');
param.name = prop;
param.value = params[prop];
obj.appendChild(param);
}
}
Now, the hard part. Like many same-like elements, <object> doesn't have specs for callbacks, so each browser behaves differently.
Chrome. On error and on load emits load event.
Firefox. Emits load and error correctly.
Safari. Emits nothing....
Seems like no different from iframe, getEntriesByType, script....
But, we have native browser fallback! So, because we set fallback (innerHtml) directly, we can tell if <object> is loaded or not
function isReallyLoaded(obj) {
return obj.offsetHeight !== 5; // fallback height
}
/**
* Chrome calls always, Firefox on load
*/
obj.onload = function() {
isReallyLoaded(obj) ? onLoaded() : onError();
};
/**
* Firefox on error
*/
obj.onerror = function() {
onError();
};
But what to do with Safari? Good old setTimeout.
var interval = function() {
if (isLoaded) { // some flag
return;
}
if (hasResult(obj)) {
if (isReallyLoaded(obj)) {
onLoaded();
} else {
onError();
}
}
setTimeout(interval, 100);
};
function hasResult(obj) {
return obj.offsetHeight > 0;
}
Yeah.... not so fast. The thing is, <object> when fails has unmentioned in specs behaviour:
Trying to load (size=0)
Fails (size = any) really
Fallback (size = as in innnerHtml)
So, code needs a little enhancement
var interval = function() {
if (isLoaded) { // some flag
return;
}
if (hasResult(obj)) {
if (isReallyLoaded(obj)) {
interval.count++;
// needs less then 400ms to fallback
interval.count > 4 && onLoadedResult(obj, onLoaded);
} else {
onErrorResult(obj, onError);
}
}
setTimeout(interval, 100);
};
interval.count = 0;
setTimeout(interval, 100);
Well, and to start loading
document.body.appendChild(obj);
That is all. I tried to explain code in every detail, so it may look not so foolish.
P.S. WebDev sucks
I had this problem recently and had to resort to setting up a Javascript Polling action on the Parent Page (that contains the IFRAME tag). This JavaScript function checks the IFRAME's contents for explicit elements that should only exist in a GOOD response. This assumes of course that you don't have to deal with violating the "same origin policy."
Instead of checking for all possible errors which might be generated from the many different network resources.. I simply checked for the one constant positive Element(s) that I know should be in a good response.
After a pre-determined time and/or # of failed attempts to detect the expected Element(s), the JavaScript modifies the IFRAME's SRC attribute (to request from my Servlet) a User Friendly Error Page as opposed to displaying the typical HTTP ERROR message. The JavaScript could also just as easily modify the SRC attribute to make an entirely different request.
function checkForContents(){
var contents=document.getElementById('myiframe').contentWindow.document
if(contents){
alert('found contents of myiframe:' + contents);
if(contents.documentElement){
if(contents.documentElement.innerHTML){
alert("Found contents: " +contents.documentElement.innerHTML);
if(contents.documentElement.innerHTML.indexOf("FIND_ME") > -1){
openMediumWindow("woot.html", "mypopup");
}
}
}
}
}
I think that the pageshow event is fired for error pages. Or if you're doing this from chrome, then your check your progress listener's request to see if it's an HTTP channel in which case you can retrieve the status code.
As for page dependencies, I think you can only do this from chrome by adding a capturing onerror event listener, and even then it will only find errors in elements, not CSS backgrounds or other images.
Doesn't answer your question exactly, but my search for an answer brought me here, so I'm posting just in case anyone else had a similar query to me.
It doesn't quite use a load event, but it can detect whether a website is accessible and callable (if it is, then the iFrame, in theory, should load).
At first, I thought to do an AJAX call like everyone else, except that it didn't work for me initially, as I had used jQuery. It works perfectly if you do a XMLHttpRequest:
var url = http://url_to_test.com/
var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status != 200) {
console.log("iframe failed to load");
}
};
xhttp.open("GET", url, true);
xhttp.send();
Edit:
So this method works ok, except that it has a lot of false negatives (picks up a lot of stuff that would display in an iframe) due to cross-origin malarky. The way that I got around this was to do a CURL/Web request on a server, and then check the response headers for a) if the website exists, and b) if the headers had set x-frame-options.
This isn't a problem if you run your own webserver, as you can make your own api call for it.
My implementation in node.js:
app.get('/iframetest',function(req,res){ //Call using /iframetest?url=url - needs to be stripped of http:// or https://
var url = req.query.url;
var request = require('https').request({host: url}, function(response){ //This does an https request - require('http') if you want to do a http request
var headers = response.headers;
if (typeof headers["x-frame-options"] != 'undefined') {
res.send(false); //Headers don't allow iframe
} else {
res.send(true); //Headers don't disallow iframe
}
});
request.on('error',function(e){
res.send(false); //website unavailable
});
request.end();
});
Have a id for the top most (body) element in the page that is being loaded in your iframe.
on the Load handler of your iframe, check to see if getElementById() returns a non null value.
If it is, iframe has loaded successfully. else it has failed.
in that case, put frame.src="about:blank". Make sure to remove the loadhandler before doing that.
If the iframe is loaded on the same origin as the parent page, then you can do this:
iframeEl.addEventListener('load', function() {
// NOTE: contentDocument is null if a connection error occurs or if
// X-Frame-Options is not SAMESITE (which could happen with
// 4xx or 5xx error pages if the corresponding error handlers
// do not specify SAMESITE). If error handlers do not specify
// SAMESITE, then networkErrorOccurred will incorrectly be set
// to true.
const networkErrorOccurred = !iframeEl.contentDocument;
const serverErrorOccurred = (
!networkErrorOccurred &&
!iframeEl.contentDocument.querySelector('#well-known-element')
);
if (networkErrorOccurred || serverErrorOccurred) {
let errorMessage;
if (networkErrorOccurred) {
errorMessage = 'Error: Network error';
} else if (serverErrorOccurred) {
errorMessage = 'Error: Server error';
} else {
// Assert that the above code is correct.
throw new Error('networkErrorOccurred and serverErrorOccurred are both false');
}
alert(errorMessage);
}
});

Categories

Resources