Using Frames More Securely
HTML frames (FRAMESETs and IFRAMEs) are a feature of all modern web browsers that enable content from multiple pages to be displayed within a single view. Historically, frames were primarily used to enable partial page updates, where page navigation was contained in one frame, and page content was contained in another. Over time, use of frames expanded to include advertising, mashup, and AJAX scenarios. Today, the majority of popular websites use IFRAMEs for myriad reasons.
From a security point of view, frames can help increase the security of web applications by creating isolation between content delivered from different sources. For instance, a Web mail account (https://mail.example.com) might choose to render HTML email within an IFRAME (https://untrusted.example.com/getmsg?msgid=1234) to ensure that any script in the HTML mail cannot execute in the context of the Web mail application delivered from mail.example.com. Instead, any script would execute in the context of the “untrusted.example.com” domain. This isolation prevents tampering with the Web mail UI, leaking user credentials and cookies, snooping on other messages, etc.
For frames rendered in Internet Explorer 6 and later, security can be further increased by setting the frame’s SECURITY attribute to the value “restricted”. Doing so causes Internet Explorer to treat the contents of the frame, regardless of their source, as content that should be rendered in the Restricted Sites Security Zone. Frames running in the Restricted Sites zone cannot run script, invoke ActiveX controls, redirect to other sites, and so on. This technique is particularly useful in cases where the frame’s content cannot be assumed to be trustworthy (as in the case of web mail scenario above).
However, it is important to understand that HTML frames are not a security panacea. In order to remain secure, a website which chooses to include content from another website in a frame must generally trust that other website to be non-malicious. Otherwise, a number of security threats are exposed.
For instance, consider a web mail application containing two IFRAMEs: one that is used to display an advertisement, and one that is used to display the contents of an HTML email.
<iframe src="https://ad.example.com/rand/1234.aspx" security="restricted"></iframe>
<iframe src="https://untrusted.example.com/getmsg?msgid=1234" security="restricted"></iframe>
In the best case, both frames are tagged with the SECURITY="restricted" attribute to ensure that the HTML email or the advertisement cannot contain any script which might be used to navigate the user away from the web mail page to a malicious site (e.g. <SCRIPT>window.location="https://evil.example.net/malice.htm"</SCRIPT>).
The user will likely recognize that the email frame contains content of questionable trustworthiness. While the email may contain a phishing attack or other malicious content, it is unlikely that the user will mistake such content as a part of the web mail application itself. In contrast, in the advertising case, unless there is an indication around the IFRAME indicating that the contents are an advertisement, the user could be fooled into taking an unsafe action. For instance, an ad banner could be crafted to match the web mail user-interface, containing text that suggests that there’s a system outage and the user should email their name and password to a given address. The user may mistake the content as a trusted message from the web mail application, and undertake an unsafe action.
Therefore, Web developer best practices for using frames can be summarized as:
- If possible, do not include frames containing content from unknown/untrusted sites.
- If possible, use the SECURITY="restricted"attribute to reduce the privileges of content in the IFRAME.
- If it is not already obvious to users, clearly mark any frames containing untrusted content.
Eric Lawrence
Program Manager
edit: adjusted quotes around "restricted"
Comments
Anonymous
January 18, 2008
I'll use it once it becomes part of any HTML standard.Anonymous
January 18, 2008
"the user should email their name and password to a given address" If there was a system outage in the web-mail application, the user wouldn't be able to send any email!Anonymous
January 18, 2008
It would be nice if this security setting could be done on a <div security="restricted"></div> for the case of things like, say, message comments!Anonymous
January 18, 2008
So, you're advocating the use of a proprietary HTML attribute that will only work in one browser? Where I work, we try to cater for all users including the ones using IE6 and 7, as silly as it may seem. So what's happening with IE8? You're not going to make us wait until Mix are you? I mean what's the point of holding back information when you can release it today?Anonymous
January 18, 2008
so does ie7 rss viewer act the same way since it has a nav frame & a content frame?Anonymous
January 18, 2008
You guys are acting as if you are surprised Microsoft care about web standards LOL. Man I can't believe people still talk about iframes. What year is this?Anonymous
January 18, 2008
Oops! My last post should have read "...Microsoft don't care about web standards." Because we all know they don't.Anonymous
January 18, 2008
what's wrong with discussing iframes? there are still webdevs out there using them and as long as they do, the IE team is empowered to help them write secure code for their sites.Anonymous
January 18, 2008
I have never used iframes. Anyway, for the webdevs who still use them, it's good to discuss :).Anonymous
January 18, 2008
I'm glad to hear this. I'm still using iframes on a couple of sites. Sometimes there is no other solution to fix a 'problem'.Anonymous
January 18, 2008
Glad to see it's a IE6 legacy and nothing new. I think were going to get better Iframe alternatives anyway with object in IE8.Anonymous
January 18, 2008
You think so? Maybe you're right, I don't know...Anonymous
January 18, 2008
The comment has been removedAnonymous
January 18, 2008
@Tweak Vista: Yes. It is already possible, however, not as good as one'd wish. It has a lot of potential though!Anonymous
January 18, 2008
IE is not the only browser on earth. Do we need to make that clear to you? And in my opinion, now IE is the worst browser ever. If it's not bundled with the OS, no one will use it.Anonymous
January 18, 2008
Hmmm http://msdn2.microsoft.com/en-us/library/ms534622(VS.85).aspx Doesn't come right out and say it, but yes, it is a proprietary attribute on frame's and iframe's. I'm with game kid, and Fish. I'm not touching this attribute with a 10 foot pole until I see a W3C spec for it. Last I checked here: http://www.w3.org/TR/html401/present/frames.html#h-16.5 It wasn't listed. To those above moaning they don't use iframes, get with the times, they are everywhere, and they fill a void that object can fulfill. I'll also agree with Fish and Daniel. This is all very good but what does this have to do with IE8? or bug tracking?Anonymous
January 18, 2008
The comment has been removedAnonymous
January 19, 2008
The comment has been removedAnonymous
January 19, 2008
The comment has been removedAnonymous
January 19, 2008
I'm sure you're right and the <a href="http://thedailywtf.com/Articles/I-am-right-and-the-entire-Industry-is-wrong.aspx">entire industry is wrong.</a>Anonymous
January 19, 2008
The comment has been removedAnonymous
January 19, 2008
Speaking of frames, why doesn't IE have options like "Show only this frame, Open frame in new window/tab, Refresh only a particular frame, Save frame as, View frame source"?Anonymous
January 19, 2008
@gamekid: I'm curious, what are you using until then? @FarStrider: The IE7 RSS viewer doesn't directly use the SECURITY attribute. Instead, the MIME handler that implements the RSS view runs the content in the restricted sites zone using native binary mechanisms. @SpeakingOf: Running an IFRAME in another window does not provide any meaningful security. The new window shares the same security context as the original window. If it didn't, new windows & frames from sites you care about (e.g. your bank) would not work correctly because they would not have access to their parent context (cookies/DOM/etc). @anonymous: Please support your claims by reporting a repro of any of these to secure@microsoft.com @KL: You bring up a good point: the intent of the SECURITY attribute is to protect against "0-click" attacks. Automatic redirections (META Refresh/Javascript) are blocked in the restricted sites zone. If the user chooses to interact with the restricted frame, say by clicking on an A tag, navigation will take place in a new window. This scenario isn't contrived: Web mail clients use this attribute today. It has been supported by the browser for over 7 years now. @Tei: IFRAMES have nothing to do with MDI/SDI; using IFRAMES does not result in top-level documents that cause the problems you've described. Escaping serves as a good defense in depth IF you have control of the content. Having said that, it's actually much more secure to use a filtering approach rather than an escaping approach, because then you can be certain that ONLY known-safe content/tags are allowed rather than attempting to make unsafe content/tags safe. In either case, it's best to combine filtering & escaping with the SECURITY attribute.Anonymous
January 19, 2008
Hello Mr Lawrence, A lot could be said about frames, security and IE here. First, what I do not understand is why the enforced security is not entirely at the browser level or at the user level (via browser settings). Why does the web author has to be involved, and here, with a proprietary attribute on top of that? Ideally, you want bad (malicious) web authors/content developers or incompetent ones to not be able to harm the user, by default...
There are several security settings regarding frames: Tools/Internet Options/Security tab/Internet Zone/Custom level...button/Miscellaneous section/ o Access data sources across domains o Lauching program and files in an IFRAME o Navigate sub-frames across different domains Which one(s) correspond to security="restricted"? Why are these settings not explained in an helpfile in Help/Content and Index or elsewhere...? You would want to help, educate, empower the IE users regarding these settings, right? So, where are help content regarding these IE settings in IE helpfiles? You see, Mr Lawrence, right there, there is IMO a weakness with IE.
"There are security problems caused by the fact that it is not visible to the user when different frames come from different sources." http://www.w3.org/TR/2002/WD-xframes-20020806/#s_intro Has Microsoft been supporting work regarding XFrames? Why bring a proprietary attribute as a "crouch" (entirely in the hands of the web author) to a security problem/concern/vulnerability? Where/how exactly can I report serious and objectively grave (incapacitating) bugs (like application crash, application hang) to Microsoft? Regards, Gérard
Anonymous
January 19, 2008
Why couldn't you have made a clearly proprietary CSS property so that designers could tell it's a property that only Internet Explorer has? Something like -ie-security:restricted; wouldn't even make the CSS validator mad.Anonymous
January 19, 2008
@Mr. Talbot: Security ~is~ enforced at a browser level; frames are not given additional permissions above the permissions of site hosting their content. So, if you put, say, ads.example.com in the restricted sites zone, then it is run with restricted permissions, regardless of whether or not the SECURITY=restricted attribute was applied. The intent of the SECURITY attribute is to permit a mash-up site to request restrictions against framed content that it either did not deliver (e.g. an injected advertisement) or that it did deliver but cannot trust (e.g. user-submitted content). In the latter case, the SECURITY attribute protects the site (not the user) against script injection attacks that could steal its cookies, etc. All of the permissions you list are denied in the restricted sites zone, as are many others. Users should never have any need to toggle any of these settings; the defaults are set the way they are to protect the user. <<Why bring a proprietary attribute>> The attribute in question has existed since 2001 or earlier. There's nothing preventing its adoption by future standards. <<Where/how exactly can I report serious and objectively grave (incapacitating) bugs (like application crash, application hang) to Microsoft?>> If you encounter a crash using IE, chances are very likely that it's caused by a buggy add-on (the majority of crashes are). You can track down buggy plugins by following the steps here: http://www.enhanceie.com/ie/troubleshoot.asp When users choose to submit crash data to Microsoft, we collect data on the crash and can determine where the failure occurred, and if the failure is in IE itself, we can make updates to IE to prevent its recurrence. If you believe you have found a security vulnerability in IE, please submit it to secure@microsoft.com Thanks, EricAnonymous
January 19, 2008
The comment has been removedAnonymous
January 19, 2008
@IE Team, you've been trying to convince the world that you take web standards seriously and you repeatedly remind us that you're an opponent of "breaking the web" - now you tell the world to use an old non-standard HTML attribute that only works in IE. I wonder how many developers knew about the 'security' attribute before, and how many developers are going to start using it because of this blog post. Check out this thread about how the security attribute can be used by Bad People: http://www.webservertalk.com/archive380-2005-12-1308076.htmlAnonymous
January 19, 2008
Some "Solution".... Installing another browser isn't going to magically remove malware. Given the number of security holes in Safari, recommending it is a joke. "Fish", why do you think frame-busting is somehow a security feature? It's not. The bad guy could just as easily proxy your html through his server. As for "Breaking the web", they're talking about backward compatibility. Since IE 6 and later support the attribute, and no other browser breaks if it's there, this feature doesn't "break" anything. Read up on defence in depth!Anonymous
January 19, 2008
@IE Team: Is there any other way to remove that thing? Coz i prefer to use IE among other browsers(although I have Firefox)Anonymous
January 19, 2008
I never said another browser would solve the problem, only avoid it in the future. Adware is the reason I stopped using IE and I haven't had any since.Anonymous
January 19, 2008
@Anonymous Coward "Why couldn't you have made a clearly proprietary CSS property so that designers could tell it's a property that only Internet Explorer has? Something like -ie-security:restricted; wouldn't even make the CSS validator mad." CSS is for styling pages, not for functionality, quite simply. Your page should still work fine with CSS disabled, too.Anonymous
January 19, 2008
Some website wont work properly if it's not on IE.. so that's whyAnonymous
January 20, 2008
> Please support your claims by reporting a repro of any > of these to secure@microsoft.com Already done that three years ago. Microsoft decided to ignore it, and to keep on ignoring it with IE7. With layer I mean a "DIV", and setting the z-index is not necessary. Injection into the parent frame isn't necessary either, since any frame to create a global event hook for keystrokes. Anyway, since the CLSID security bug all those things are just complicated in comparison to simply runnign arbitrary ActiveX controls.Anonymous
January 20, 2008
@Anonymous: IE takes reports of security vulnerabilities seriously. Please send me (ericlaw at Microsoft) the threads you had with secure, or at least a link to the repro(s). Thanks.Anonymous
January 20, 2008
Seems like the Firefox developers also like this feature. See the enhancement request #341604 on Bugzilla. http://bugzilla.mozilla.org/show_bug.cgi?id=341604Anonymous
January 21, 2008
hi , I recentyly write an activeX which is used in IE. In the activeX, i used the CHtmlEditView. In IE6, i called CHtmlEditView->image to insert an image, it work normally, but i IE7.0, i called CHtmlEditView, when i insert an image, it can't display the image. I notice that , when i inserted a jpg, png ,it worked good, but if i insert a gif, it faied. Is it a bug for IE7 or CHtmlEditView??? Who know the answer??Anonymous
January 21, 2008
@EricLaw [MSFT] All good points, but there is one thing missing. Sending an email to ericlaw at Microsoft or secure@microsoft is NOT how a public bug tracking system works. If you want the community to offer up sincere, valuable information on bugs and security breaches you need to provide a sincere service to allow for uploading attachments, providing links to test cases and most importantly access to track the status of each bug, links to patches and workarounds. We've indicated on numerous occasions that we are more than happy to be part of the development/testing process, but we expect and deserve to be treated better and have access to critical information for us to do OUR job. You want to know about legitimate bugs so that you can fix them. BUT we need to know (just as much) about these bugs so that we can avoid them, or workaround them, or ensure we update our systems (or client's systems) to avoid problems. Waiting for a serious commitment from Microsoft.Anonymous
January 21, 2008
Gordon... That's silly. No browser tracks security bugs in public; doing so is reckless. Mozilla security bugs are private until they are fixed. Opera works in a similar way, as does safari. Now, if you want to talk about non-security bugs, fine, but don't pretend like they're the same thing.Anonymous
January 21, 2008
The comment has been removedAnonymous
January 21, 2008
Vocês has that to make as the Firefox, when of the error in the IE8 open sites eestavam and lose what it was making, saved it and when to open it the sites they will come back again to be open.Anonymous
January 21, 2008
@Frank, I'm not suggesting that a Security Bug should be tracked publicly, however it should be tracked in the same bug tracking system that all the public bugs are tracked in (e.g. 1 System) Thus if I have 20 bugs filed, I go to 1 location to track the status of all of them. If a bug is flagged as security related, then ONLY Microsoft and I can access it, track the progress and fix for it. If Microsoft decides after the fix has been released to also release the info on the bug, so be it. My point which is still quite relevant is that the "email me the issue" tactic here is not the way to do professional development of a web browser platform that thousands of developers use and depend on daily. If I submit a bug to Microsoft that no one else can track, whats the point. I haven't helped anyone with their past/present/future struggle with the issue.Anonymous
January 21, 2008
In my opinion, now IE is the worst browser ever. If it's not bundled with the OS, no one will use it...Anonymous
January 21, 2008
i strongly desagree with ie is the worst browser. sure there is a list of browser not so good and i think soon we wil have a different idea about it.Anonymous
January 21, 2008
@Gordon 1- The nr 1 problem with a public bug tracking system (PBTS) is that Microsoft would get a mix of bug reports regarding IE 6 specifically, regarding IE 7 specifically and regarding IE 6 and IE 7 but fixed in IE 8 (or about to). Considering that the userbase of IE is several hundreds of millions, you would get most likely a lot of noise and very little useful signal... and a huge amount of time, energy, personel to untangle all this. So, IMO, it's not worth it at this time. Once IE 8 beta 1 is out, then it would make a lot of sense to provide a PBTS for IE 8 only and specifically and with insisting that people follow bug writing guidelines. Such IE 8 PBTS would allow to track a list of bugs occuring in IE 8 and then check/follow-up for regression. 2- If you visit and surf places like bugs.webkit.org or bugs.kde.org or even bugzilla.mozilla.org, you will see/notice that the objective quality (usefulness, reduced testcase, clear report, etc) of bugs being reported varies a lot. I remember a regular mozilla bugzilla stating that even an important minority of confirmed bugs' objective quality was overall not that good. Again, you want efforts/typing/time of employees to be concentrated on fixing bugs, not on untangling very poorly written webpages, on resolving as duplicates (DUP), etc.. 3- Right now, Microsoft can view, examine, investigate at least 750 bug reports - excellent bug reports regarding spec violations, well written, well built - that actually happen in IE 7. They just have to visit the webpages of Bruno Fassino, Alan Gresley, Simon Pieters, Robin Lionheart, Ingo Chao, David Hammond, Dan, Tino Zijdel, Nick Rigby, Ingo Turski, incutio.com, Mark Wilton-Jones, etc..., and my IE 7 bugs webpage. So, right now, there is no urgent, no immediate need to implement a PBTS. You see, there are already so many bugs being reported and bug reports with good working quality that Microsoft can go and jump immediately into fixing those already well-defined bugs. And here, I'm not even mentioning the official CSS 2.1 Test suite (and other official test suites) and Ian "Hixie" Hickson extensive test suite (covering CSS, DOM, HTML) for browsers. And here, I'm not even mentioning unsupported DOM 1 and DOM 2 attributes, methods, interfaces and unsupported CSS 2.1 properties. 4- Microsoft's agenda is not the web authors' agenda nor the web standards movement's agenda. There are some common denominator, overlapping areas of agreement when one superpose, overlap those 3 agendas. Microsoft's main/primary goal, primacy is making its share holders happy and about profitability. Microsoft is a business, profit-driven. You can not say the same with KDE, Mozilla, WebKit, TKHTML, etc. So a solution, a perfect tool applying to them may not be transposed, transferred, just like that, to Microsoft. Even Opera does not have a public bug tracking system. Regards, GérardAnonymous
January 21, 2008
The comment has been removedAnonymous
January 21, 2008
The comment has been removedAnonymous
January 21, 2008
The comment has been removedAnonymous
January 23, 2008
The comment has been removedAnonymous
January 25, 2008
I have never used iframes. Anyway, for the webdevs who still use them, it's good to discuss :).Anonymous
January 29, 2008
iframes sound practical. I'm unconvinced as to why everybody doesn't use them. It's just like user a "hacker-safe" program.Anonymous
February 11, 2008
If you want the content to be searchable and indexed, then an IFrame is not the way to go, however, they are great for delivering separate (and disparate) content, and for security reasons as you rightly state. I use IFrames a lot, but they are relatively limited. I also dislike the fact others can effectively show my content with their own ads / messages next to it using iframes.