Why do some websites (like facebook) load scripts in an iframe?
Is this to allow the site to load more than 2 resources at a time because the iframe's resources are at different URLs?
What you are seing, might be an application of "Comet" communication, using a hidden iframe as data channel. A short explanation of the technique according to Wikipedia:
A basic technique for dynamic web application is to use a hidden IFrame HTML element (an inline frame, which allows a website to embed one HTML document inside another). This invisible IFrame is sent as a chunked block, which implicitly declares it as infinitely long (sometimes called “forever frame”). As events occur, the iframe is gradually filled with script tags, containing JavaScript to be executed in the browser. Because browsers render HTML pages incrementally, each script tag is executed as it is received.
This could be used for something like a chat, where messages are expected to appear without noticeable delay, and preferably without periodical "polling" for new data. If this is what you have come across, you should see several <script> elements in the frame, and more should be added as times go by.
EDIT
So to actually address your question... I don't know! The following information might be helpful, however:
Facebook prepends all of the JS variables and functions with your application ID.
var ID;
becomes
var 1262682068026-ID;
This limits the scope of your javascript to only your application so you can't use the DOM to get at their friends, phone number, email, address, etc, unless authorized. It makes a little sub-sandbox for you to play in.
More info on scoping here:
Facebook Docs
javascript loaded in iframe have no access to parent page objects (cross-domain restriction)
They load comet (aka comet, HTTP Push, long-lived, etc) connections in an iFrame because Internet Explorer eventually drops it:
http://cometdaily.com/2007/10/25/http-streaming-and-internet-explorer/
As it is effectively a continuous long poll, this is a blocker, this hack also increases IE's 2 connection limit leading to better responsiveness, background info:
http://alex.dojotoolkit.org/2006/02/what-else-is-burried-down-in-the-depths-of-googles-amazing-javascript/
Related
I'm trying to create a secure Darknet with WebRTC DataChannels in pure HTML, so I'm not interested about to know when an iframe has been fully loaded, but instead I'm interested to capture the iframe elements (inline images and so) using a custom scheme so I can be able from the parent page (the one connected to the Darknet) to do the real request and response with the actual data. With FirefoxOS mozbrowserlocationchange event of the Browser API objects (an extension to iframes) I could be able to capture the user navigation, cancel it, do the real request on the Darknet and later inject the iframe with the real content fetched by the parent page, but how could I be able to do the same with inline images and scripts on this loaded page? Or is this not currently possible and should I ask to them about add this functionality?
Obviously, I don't have any control about the iframes content pages, so they would be created by whatever and in any way, and also the usage of Browser API is just because seems to be the most useful to whan I'm trying to do, ideally it would be perfect if this is possible to achieve with plain iframes... :-)
Update:
A half-solution I have thinking about would be since I could be able to capture the mozbrowserlocationchange event to do the real content request of the HTML page and before fill the iframe with it do the request of their linked images and scripts and set them inline to prevent the iframe from doing more request. This would only lead to somewhat very simple web pages compared to current web standards (no AJAX, no async loading of script tags...) but definitely it would be usable up to some point :-)
Anyway, is there any other better alternative?
That sounds like something, that would be possible (straightforward, even) as soon as Service Controllers (previously known as NavigationControllers) are implemented, but I do not know any way to accomplish this via any currently available method.
No wonder you didn't find info about this - the proposal is called "Service workers" (though, previously this was called Event workers, and even before that, they were called - guess what - navigation controllers). This is a lively spec! ;) Find the working draft on GitHub: https://github.com/slightlyoff/ServiceWorker/ with a lengthy explainer document that should get you going.
Also, there is a document with the current Chrome (blink) implementation plans.
I made a tool that grabs all html, css, javascript and images from other websites (any kind).
Then i execute this on my own domain name (after modification of links of course).
The javascript also executes, so the page render is identical as on the grabbed website. But all under my domain name.
Is there any method to secure this javascript execution (with uncontrolled code) so that the grabbed site will not be able to get cookies of the users of my website ? (or other potential security breach?)
Thanks.
thought you should never execute random js on your page.
still i think there is one way to do it though it requires huge amount of effort.
onces your pages gets loaded. override all the global variables of javascript that the browser injects to your own implementation and implement security checks in there. this way all the random js being executed in your page will access all the functionalities that way you want them to do
ex. override document.cookie to something else on pageload which then execludes that cookies of your domain.
change the protoype of xmlHttprequest so that ajax requests to your domain are blocked. etc etc
Running the random page on a separate origin (i.e. running it on a separate domain) will at least avoid data leaks (cookies, localStorage, etc) between the random page and your site. To avoid leaks from one random page to an other, maybe also run each random page on its own sub-domain.
I believe this is what google does for the cache; the pages are served from the googleusercontent.com domain: https://webcache.googleusercontent.com/search?q=cache%3Astackoverflow.com&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fr:official&client=firefox-a
There is no way to prevent data leaks without running the page on a separate domain.
How can I stop loading a web page if it uses a frame-buster buster as mentioned in this question, or an even stronger X-Frame-Options: deny like stackoverflow.com? I am creating a web application that has the functionality of loading external web pages into an <iframe> via javascript, but if the user accidentally steps on to websites like google.com or stackoverflow.com, which have a function to bust a frame-buster, I just want to quit loading. In stackoverflow.com, it shows a pop up message asking to disable the frame and proceed, but I would rather stop loading the page. In google, it removes the frame without asking. I have absolutely no intent of click jacking, and at the moment, I only use this application by myself. It is inconvinient that every time I step on to such sites, the frames are broken. I just do not need to continue loading these pages.
Edit
Seeing the answers so far, it seems that I can't detect this before loading. Then, is it possible to load the page in a different tab, and then see if it does not have the frame-buster buster, and then if it doesn't, then load that into the <iframe> within the original tab?
Edit 2
I can also acheive the header or the webpage as an html string through the script language (Ruby) that I am using. So I think I indeed do have access to the information before loading it into an <iframe>.
There's no way to detect this before loading the page since the frame busting is done via a header or is triggered via JavaScript as the page is loading.
Without a server backend you won't be able to as you are pretty limited with the amount of tinkering you can do in javascript due to crossdomain policies.
You might want to consider creating some sort of a blacklist for URLs to stay away from...
I need to be allow content from our site to be embeded in other users web sites.
The conent will be chargeable so I need to keep it secure but one of the requirements is that the subscribing web site only needs to drop some javascript into their page.
It looks like the only way to secure our content is to check the url of the page hosting our javascript matches the subscribing site. Is there any other way to do this given that we don't know the client browsers who will be hitting the subscribing sites?
Is the best way to do this to supply a javascript include file that populates a known page element when the page loads? I'm thinking of using jquery so the include file would first call in jquery (checking if it's already loaded and using some sort of namespace protection), then on page load populate the given element.
I'd like to include a stylesheet as well if possible to style the element but I'm not sure if I can load this along with the javascript.
Does this sound like a reasonable approach? Is there anything else I should consider?
Thanks in advance,
Mike
It looks like the only way to secure our content is to check the url of the page hosting our javascript matches the subscribing site.
Ah, but in client-side or server-side code?
They both have their disadvantages. Doing it with server-side code is unreliable because some browsers won't be passing a Referer header at all, and if you want to stop caches keeping a copy of the script, preventing the Referer-check from taking place, you have to serve with nocache or Vary: Referer headers, which would harm performance.
On the other hand, with client-side checks in the script you return, you can't be sure your environment you're running in hasn't been sabotaged. For example if your inclusion script tag was like:
<script src="http://include.example.com/includescript?myid=123"></script>
and your server-side script looked up 123 as being the ID for a customer using the domain customersite.foo, it might respond with the script:
if (location.host.slice(-16)==='customersite.foo') {
// main body of script
} else {
alert('Sorry, this site is not licensed to include content from example.com');
}
Which seems simple enough, except that the including site might have replaced String.prototype.slice with a function that always returned customersite.foo. Or various other functions used in the body of the script might be suspect.
Including a <script> from another security context cuts both ways: the including-site has to trust the source-site not to do anything bad in their security context like steal end-user passwords or replace the page with a big goatse; but equally, the source-site's code is only a guest in the including-site's potentially-maliciously-customised security context. So a measure of trust must exist between the two parties wherever one site includes script from another; the domain-checking will never be a 100% foolproof security mechanism.
I'd like to include a stylesheet as well if possible to style the element but I'm not sure if I can load this along with the javascript.
You can certainly add stylesheet elements to the document's head element, but you would need some strong namespacing to ensure it didn't interfere with other page styles. You might prefer to use inline styles for simplicity and to avoid specificity-interference from the page's main style sheet.
It depends really whether you want your generated content to be part of the host page (in which case you might prefer to let the including site deal with what styles they wanted for it themselves), or whether you want it to stand alone, unaffected by context (in which case you would probably be better off putting your content in an <iframe> with its own styles).
I'm thinking of using jquery so the include file would first call in jquery
I would try to avoid pulling jQuery into the host page. Even with noconflict there are ways it can conflict with other scripts that are not expecting it to be present, especially complex scripts like other frameworks. Running two frameworks on the same page is a recipe for weird errors.
(If you took the <iframe> route, on the other hand, you get your own scripting context to play with, so it wouldn't be a problem there.)
You can store the users domain, and a key within your local database. That, or the key can be an encrypted version of the domain to keep you from having to do a database lookup. Either one of these can determine whether you should respond to the request or not.
If the request is valid, you can send your data back out to the user. This data can indeed load in jQuery and and additional CSS reference.
Related:
How to load up CSS files using Javascript?
check if jquery has been loaded, then load it if false
I'm just looking for clarification on this.
Say I have a small web form, a 'widget' if you will, that gets data, does some client side verification on it or other AJAX-y nonsense, and on clicking a button would direct to another page.
If I wanted this to be an 'embeddable' component, so other people could stick this on their sites, am I limited to basically encapsulating it within an iframe?
And are there any limitations on what I can and can't do in that iframe?
For example, the button that would take you to another page - this would load the content in the iframe? So it would need to exist outwith the iframe?
And finally, if the button the user clicked were to take them to an https page to verify credit-card details, are there any specific security no-nos that would stop this happening?
EDIT: For an example of what I'm on about, think about embedding either googlemaps or multimap on a page.
EDIT EDIT: Okay, I think I get it.
There are Two ways.
One - embed in an IFrame, but this is limited.
Two - create a Javascript API, and ask the consumer to link to this. But this is a lot more complex for both the consumer and the creator.
Have I got that right?
Thanks
Duncan
There's plus points for both methods. I for one, wouldn't use another person's Javascript on my page unless I was absolutely certain I could trust the source. It's not hard to make a malicious script that submits the values of all input boxes on a page. If you don't need access to the contents of the page, then using an iframe would be the best option.
Buttons and links can be "told" to navigate the top or parent frame using the target attribute, like so:
This is a link
<form action="http://some.url/with/a/page" target="_parent"><button type="submit">This is a button</button></form>
In this situation, since you're navigating away from the hosting page, the same-origin-policy wouldn't apply.
In similar situations, widgets are generally iframes placed on your page. iGoogle and Windows Live Gadgets (to my knowlege) are hosted in iframes, and for very good reason - security.
If you are using AJAX I assume you have a server written in C# or Java or some OO language.
It doesn't really matter what language only the syntax will vary.
Either way I would advise against the iFrame methods.
It will open up way way too many holes or problems like Http with Https (or vice-versa) in an iFrame will show a mixed content warning.
So what do you do?
Do a server-side call to the remote site
Parse the response appropriately on the server
Return via AJAX what you need
Display returned content to the user
You know how to do the AJAX just add a server-side call to the remote site.
Java:
URL url = new URL("http://www.WEBSITE.com");
URLConnection conn = url.openConnection();
or
C#:
HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create("http://www.WEBSITE.com");
WebResponse res = req.GetResponse();
I think you want to get away from using inline frames if possible. Although they are sometimes useful, they can cause issues with navigation and bookmarking. Generally, if you can do it some other way than an iframe, that is the better method.
Given that you make an AJAX reference, a Javascript pointer would probably be the best bet i.e. embed what you need to do in script tags. Note that this is how Google embed things such as Google Analytics and Google Ads. It also has the benefit of also being pullable from a url hosted by you, thus you can update the code and 'voila' it is active in all the web pages that use this. (Google usually use version numbers as well so they don't switch everyone when they make changes).
Re the credit card scenario, Javascript is bound by the 'same origin policy'. For a clarification, see http://en.wikipedia.org/wiki/Same_origin_policy
Added: Google Maps works in the same way and with some caveats such as a user/site key that explicitly identify who is using the code.
Look into using something like jQuery, create a "plugin" for your component, just one way, and just a thought but if you want to share the component with other folks to use this is one of the things that can be done.