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).
Related
Now I know there are a lot of resources about same origin policy, but I just want a straight up answer for my specific query as I am really struggling to understand.
I am using Facebook plugins on my website, these create iframes that are only visible in the DOM when I use chromes inspect element etc.
Is there a way that I can access these iFrames properties/attributes at all, or is it a resounding "NO CHANCE!". I am spending far too much time on this and I just need to get a final verdict.
Thanks!
Javascript doesn't see the iframe content. Chrome inspector just loads 2 different websites in the same time, yours and the plugins one, so you can play with both of them.
Just curious, how would you like to change it?
In general, JavaScript cannot access iframe content from outside of the iframe, unless the page domain and the iframe domain share the same protocol and host and port. In your case, this could possibly be done using a proxy server to load the iframe content from your domain.
http://en.wikipedia.org/wiki/Same_origin_policy
Some websites has a script that will redirect it to the original site if you tried to put it on an iframe. So to solve this, we have add the property sandbox="allow-scripts" to the iframe tag. But this solution will not work on browser that doesn't support html5. How can we resolve this? Additionally, we still want to have the script activated on the inner pages.
Ask the owners/administrators of the site to give you an authenticated URL for the site that doesn't redirect.
If you're trying to do this without the permission of the owners/adminstrators, then please reconsider your design.
It sounds like the original post is mentioning a frame-busting script which is in place to keep the page contents from being framed, usually to combat click-jacking attacks.
If you have permission from the site you are trying to frame, aka you have a legitimate reason to be framing their site, you should work with the owners of that site to find a work around. One such method would be to have them replace their frame-busting script with an X-Frame-Options header that could list your domain as an allowed domain to frame the content.
Is there any way to run a bookmarklet on an iFrame which is from a different domain?
For example, I have a page loaded from http://example.com, which has an iFrame whose source is set to http://example2.com. When I run the bookmarklet, it is always run on http://example.com, since that is the main page. I want to run it on the other iFrame though.
When I attempt to interact with the iFrame (e.g. by changing its source attribute to javascript:alert('test')), Chrome shows the following error:
Unsafe JavaScript attempt to access frame with URL http://example.com from frame with URL http://example2.com. Domains, protocols and ports must match.
I tried dragging and dropping the bookmarklet into the frame, but it says:
Failed to load resource
Is there any way for me to interact with an iFrame using a bookmarklet in Chrome?
There is a way to do cross-domain message-passing (not arbitrary code execution) using window.postMessage, yet all a frame A can do to frame B (when they are not of the same origin) is passing it a message hoping that B has a callback function listening for this message.
So here if you control exemple2.com (what's in the frame that don't get the bookmarklet), you can make the bookmarklet pass a message to the iframe and handle it in the iframe.
Else I don't think you have a solution here, except very complicated ones (like proxying).
Other links:
In-depth article about same origin policy and its implementations in browsers
A cross-browser, backward compatible postMessage attempt (as jQuery plugin)
iFrames have alot of security on them as do ajax calls.
Any attempt to use these in a cross-domain manner will result in a security error.
Imagine you were able to interact with other iFrames on different domains. You would be able to make an iFrame (like facebook login's page) that had width and height of 100% and add a function to execute on a submit event which would email you the username and pass before submitting.
So you're gonna have a lot of trouble accomplishing what you're trying to do. You basically can't mess with a page that you don't own. You can use firebug to edit it with the html tab though.
Hope that helps
One option if you are not in control of the page or the iframe is to load the iframe into a new window. The src attribute of the iframe is available to read by the parent JS, which can then open a new tab or window. The user can then click on the bookmarklet a second time to load it into this new page.
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
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).