Using iframes to sandbox untrusted code

Question

I'm trying to create an extensible platform, where my site will provide a model and some views (both client-side, in the browser) and third party sites may add their own views as well. The goal here is that only my model will make HTTP requests to my server, and the third party views shall only make API calls to my platform, nothing more (they may also "call home" if they want to, but they must not touch anything not explicitly exposed to them through the API).

The proposed solution is creating an invisible iframe for each third party extension, using only postMessage to communicate with them (Edit: to be a proper "view" it must be visible, of course, but as an alternative it can merely have the role of "controller", delegating the render of visual components to the main page - could be used if it added any security benefits, but ideally no). Would this properly "sandbox" the code? I'm assuming that:

• They won't be able to access the DOM of the main page, or make arbitrary JavaScript calls on it, or make Ajax request on my domain, due to same-origin policy;
• They might make GET requests on my server (including loading scripts from it), but as long as I use CSRF tokens where it matters I should be fine. This situation is no different from having two open tabs in the same browser, one of them authenticated with its respective site;
• They won't be able to clickjack the user, since if their iframes are invisible; I'm also assuming they can't make them visible or resize them, since this would involve accessing the DOM of the parent page, is this correct?
• They can spam Window.alert (or worse: Window.prompt), console.log or access other "global" stuff. This is the worse problem I identified so far, and still unable to think of ways to prevent that.
  • Clarifying: the issue here is the possibility of trying to impersonate the parent site, displaying a message asking for the password, for instance.
  • Also, correct me if I'm mistaken - I'm assuming JavaScript in iframes has equal access to those resources, and no way for parent page to deny that.
• They can embed flash or other plugins which may have security vulnerabilities. The fact it's in an iframe, however, does not make it worse in any regard, or am I mistaken?

Are these assumptions correct, is there anything else I should be aware of? Some level of trust will be necessary from the part of users (the idea is that each user should be able to choose extensions at his own leisure, regardless of my site endorsing them or not, while ultimately bearing the consequences of his choices), but I'd like to do everything possible to mitigate those risks.

---

Update: I'd like to clarify the question a bit, based on the questions raised by commenters. There are many reasons to include third-party scripts in a page - advertisement, analytics, interaction with social networks, etc. This is a security concern though, in fact it's one of the reasons people use AdBlock or NoScript (so you can seletively choose which domains are allowed to run code in your browser). Usually the site trusts the third parties whose scripts it includes, but not always (Facebook applications, for instance, can be made by anyone - but they run inside a Facebook page), and I have seen iframes been used to "isolate" third-party contents.

Though one option for cross-site communication in the browser is having two open tabs (or windows) using postMessage to exchange messages, a single page provides a more seamless experience. The full implications of using iframes (visible or invisible), and its viability in sandboxing untrusted contents, is my main concern in this question, and IMHO is applicable for a wider audience too (see paragraph above).

In my particular case, I'm trying to avoid having the embedded contents impersonate the parent site (see clarification in the 4th bullet point above) and to protect users in general from other nuisances as far as I can. While each user will have the capability to choose his own extensions, being ultimately responsible for the consequences, I'd like to mitigate any known problems that are within my reach (and try to educate users for those that aren't).

Answer 1

You said you are going to load the third-party content in an iframe, but will the third-party content be hosted from the same domain as your main content, or will it be served from a separate domain?

If the third-party content is hosted on the same domain as your main page, then no, your approach is totally insecure. Content in an iframe has full scripting access to the main page, if it is served from the same origin (roughly, the same domain). Read about the same-origin policy.

A more reasonable approach is to host the third-party extension content on a different domain than your main page. If you do this, then yes, your approach gives reasonable security. The extension content will be sandboxed and will be unable to mess with the main page (for the most part). There are some remaining risks, noted below:

• The third-party content in the iframe can navigate the main page (e.g., by setting window.location or top.location). Thus, the third-party content replace the entire page with content of the third party's choosing. This might allow for phishing or spoofing attacks. An alert user might notice such attacks, because the URL in the browser's address bar will change, but some users might not notice.

• The third-party extension can still load unsavory content in its own iframe (e.g., porn, ads, etc.).

• The third-party extension can still try to mount drive-by download attacks on your users. If your users have a vulnerable browser, they might get infected by the attack (of course, this may be true if they visit any malicious site; there is nothing about iframes that increases the risk -- it just doesn't make it go away, either).

• The third-party content can play movies or sound, possibly annoying users.

• The third-party extension may be able to mount click-jacking attacks on the main page. (You mention that the iframe will be invisible, but I'm not sure exactly what are the specific methods needed to ensure that this is a robust defense against click-jacking. There are a lot of browser quirks out there.)

• It is important that your site use strong CSRF defenses. Otherwise, the third-party content will be in a perfect position to mount CSRF attacks.

Many of these risks are relatively minor and may be acceptable in most cases, but I wanted to outline them for you and for others.

An alternate approach is to use a system for Javascript sandboxing (these can also be thought of as a way to build a "virtual iframe"). See, e.g., Caja, SES, ADsafe, FBJS, and Microsoft's Web Sandbox.

You could also look at sandboxed iframes, but I don't think they're supported on all browsers, so you can't rely upon this mechanism for security yet (sadly).

See also What risks should I be aware of before allowing advertisements being placed on my website?, Security issues using iframes, How to scan Javascript for malicious code?.

Also, for details about browser quirks relating to the same-origin policy and that sort of topic, I highly recommend the Browser Security Handbook.

Answer 2

If you visit this demo you'll see that the code detects itself in a frame (can be modified to detect what page its on) than changes the url. A url which may impersonate the parent site. (sidenote i notice google and yahoo came up blank and i believe its bc their headers send "X-Frame-Options:SAMEORIGIN")

I dont know much about controlling windows so it may be possible for another window to close your site and launch another window to impersonate it. But from a DOM and javascript standpoint it should be safe for their code to execute w/o causing your users harm. However tricking the users is another story.