HTML frames and security

Introduction

Frames were introduced into HTML (via the 'frameset' and 'iframe' elements) in order to provide an element of modularity to navigable websites [1] - one or more HTML documents could include a separate menu document directly so that navigation links didn't need to be
edited in each individual document. This found particular favour in online magazines.

Using frames for such modularity became popular because many website hosting companies initially disabled, by default, other mechanisms which could be used to provide this functionality (such as CGI scripts, server-side includes, and other server-side scripting
alternatives).

Frame security

There are, broadly-speaking, two security issues with HTML frames:

1. A developer including content from another site in an iFrame is taking a risk that this content will not do anything harmful (where 'harmful' includes manipulating parent document resources (via the DOM), running malware (a malicious 3rd-party plugin, for example) or
running scripts that consume inordinate amounts of client resources such as CPU or memory.

2. A malicious developer might include content from a victim site in a frame in order to either confuse the user into performing some action at the victim site (a kind of phishing) or simply use the user's resources (browser cookies, for example) to perform an attack on the victim server (such attacks include but are not limited to, XSS).

HTML 5 'sandbox' attribute

HTML5 has added a new attribute to the iframe element, and defined a new MIME media type to indicate such sandboxed content [3]. The sandbox attribute and related work is intended to deal with security issue 1 (see above).

Multi-process Web browsing

Microsoft's Gazelle and Google's Chromium are two browser projects which attempt to limit the access by individual Web components to browser resources, by allocatng browser resources on a per-origin basis. An individual browser tab displaying content from a particular
URL renders content via a separate OS-level process from the main browser process, and from processes associated with other Web origins.

The Facebook 'Like' Button - iframes taking advantage of a security hole

Facebook's Like button functionality takes advantage of a security vulnerability to allow Facebook to display user content (some of my friends' faces, for example) in an iframe.

If you include the code Facebook generates for you, you get an iframe:

<iframe src=\"http://www.facebook.com/plugins/like.php?

href=http%3A%2F%2Fexample.com%2Fpage%2Fto%2Flike&amp;

layout=standard&amp;show_faces=true&amp;

width=450&amp;action=like&amp;

colorscheme=light&amp;height=80\" scrolling=\"no\" frameborder=\"0\" style=\"border:none; overflow:hidden; width:450px; height:80px;\" allowTransparency=\"true\"></iframe>

And of course, this iframe uses the Facebook cookie that you have because yes, you're logged into Facebook right now (right?) to display your friends' faces in the rendered like button, even when that like button appears on your own site.

It'll also use that logged in session to display the fact that you (the user at that website) like the content.

You *can't* include Facebook's like button content on the server-side if you want it to work as intended - because that content needs the user session cookie, which is only available on the client-side. So you can't follow my first or second recommendations below.

The other implication here is that it is possible for a malicious website to make the user 'like' some content hosted by someone other than the the website hosting the like button (just set the href attribute of the iframe src call to some other value than your own content). Arnab Nandi has written some excellent posts about this issue at [8] and [9].

Recommendations for Web Developers

• Include potentially untrusted content on the server-side (rather than by using iframes), and use solutions such as Google Caja [6] to sanitize all of your content prior to delivery over the Web.

• Reduce or remove the reliance on Web browser cookies in order to prevent misuse of those cookies by a malicious Website. If user confirmation of an action is important, then offer a confirmation page for the user in addition to a cookie-based session identifier when confirming something that appears to be a user action.

• Properly validate or sanitize (by encoding) input delivered via HTTP headers, HTML POSTed data, and URL query parameters, in order to prevent cross-site scripting vulnerabilities. Review the OWASP website regarding untrusted user input [7].

• Ensure that an HTTP GET to a resource under your control does not perform an action with side-effects (such as immediately confirming a subscription or other action), since an HTTP GET which takes place via a redirect may be sent from a malicious site without requiring additional user confirmation for the redirect to occur.

References

• [1] WWW Framing (http://en.wikipedia.org/wiki/Framing_(World_Wide_Web))
• [2] Server-side include security in Apache (http://httpd.apache.org/docs/current/misc/security_tips.html#ssi)
• [3] The HTML5 iframe sandbox (http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox)
• [4] Chromium multi-process architecture (http://www.chromium.org/developers/design-documents/multi-process-architecture)
• [5] Microsoft Gazelle (http://research.microsoft.com/apps/pubs/default.aspx?id=79655)
• [6] Google Caja (http://code.google.com/p/google-caja/)
• [7] OWASP Injection and XSS Prevention (http://www.owasp.org/index.php/Top_10_2010-A1), (http://www.owasp.org/index.php/Top_10_2010-A2)
• [8] Deceiving Users with the FB Like Button(http://arnab.org/blog/deceiving-users-facebook-button)
• [9] Reputation Misrepresentation(http://arnab.org/blog/reputation-misrepresentation)