IE8 Security Part VI: Beta 2 Update
Now that Beta 2 has released, I want to provide a short update on some of the smaller security changes the team has recently made. I’ve also linked to a great article on the IE8 XSS Filter implementation written by the architect of that feature.
Restricting document.domain
The document.domain property initially returns the fully qualified domain name of the server from which a page is served. The property can be assigned to a domain suffix to allow sharing of pages across frames from different hostnames. For instance, two frames running at app1.example.com and app2.example.com can script against one another if both frames set their document.domain to their common example.com. A frame may not set its domain property to a top-level-domain, nor to a different domain suffix. For instance, app1.example.com cannot set its domain property to .com or microsoft.com. The HTML5 proposal formalizes the algorithm used to determine if a given domain property assignment is permitted, and it specifically requires that the assigned value is a suffix of the current value.
In Internet Explorer 7, the following set of calls would succeed:
// initial document.domain is app1.example.com
document.domain = "app1.example.com"; // 1. Domain property set to default value
document.domain = "example.com"; // 2. “Loosen” domain
document.domain = "app1.example.com"; // 3. “Tighten” domain
In Internet Explorer 8 and other browsers, the 3rd assignment will throw an exception, because app1.example.com is not a suffix of the then-current value, example.com.
Put simply, once you’ve loosened document.domain, you cannot tighten it.
Web Applications that need to interact with data from other domains may wish to consider using the postMessage() or XDomainRequest APIs rather than adjusting the document.domain property.
Restricting Frame-Targeting
HTML5 also specifies the circumstances in which one frame is permitted to use the targetname parameter of a window.open() call to navigate another named frame or window.
The rules are meant to help prevent a window injection vulnerability. In a window injection attack, a malicious website in one browser frame attempts to “hijack” a frame or popup owned by a trusted webpage.
For instance, consider the scenario where https://contoso.com opens a popup window with the name helpPage.
window.open("helpTopic.htm", "helpPage", "height=200,width=400");
If another page at https://evil.example.com attempts to hijack this window, like so:
window.open("spoof.htm", "helpPage", "height=200,width=400");
…instead of navigating the helpPage window owned by Contoso.com, spoof.htm will instead open in a new browser window. While Internet Explorer 7 and 8 always show an address bar on every window, this new restriction makes window injection spoofs even less convincing.
MIME-Handling: Sniffing Opt-Out
As discussed in Part V of this blog series, Internet Explorer’s MIME-sniffing capabilities can lead to security problems for servers hosting untrusted content. At that time, we announced a new Content-Type attribute (named “authoritative”) which could be used to disable MIME-sniffing for a particular HTTP response.
Over the past two months, we’ve received significant community feedback that using a new attribute on the Content-Type header would create a deployment headache for server operators. To that end, we have converted this option into a full-fledged HTTP response header. Sending the new X-Content-Type-Options response header with the value nosniff will prevent Internet Explorer from MIME-sniffing a response away from the declared content-type.
For example, given the following HTTP-response:
HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain;
X-Content-Type-Options: nosniff<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>
In IE6 and IE7, the text is interpreted as HTML:
In IE8, the page is rendered in plaintext:
Sites hosting untrusted content can use the X-Content-Type-Options: nosniff header to ensure that text/plain files are not sniffed to anything else.
XSS Attack Surface Reduction: CSS Expressions Disabled IE8 Standards Mode
Also known as “Dynamic Properties,” CSS expressions are a proprietary extension to CSS that carry a high performance cost. CSS Expressions are also commonly used by attackers to evade server-side XSS Filters.
As of Beta 2, CSS expressions are not supported in IE8 Standards Mode. They are still supported in IE7 Strict and Quirks mode for backward compatibility. While the IE8 XSS Filter can block attempts to reflect CSS Expressions as part of an XSS attack, blocking them in IE8 Standards Mode brings a performance benefit, improves standards-compliance, and acts as an attack surface reduction against script injection attacks.
Deep Dive on the IE8 XSS Filter
David Ross, architect of the IE8 XSS Filter has published a technical article on the architectural and implementation details of the XSS Filter over on the Secure Windows Initiative blog. If you’re interested in the nitty-gritty details of how the XSS Filter operates, please take a look.
Thanks for reading!
Eric Lawrence
Program Manager
Internet Explorer Security
edit: added IE6: In IE6 and IE7, the text is interpreted as HTML
Comments
Anonymous
September 02, 2008
PingBack from http://housesfunnywallpaper.cn/?p=3758Anonymous
September 02, 2008
The comment has been removedAnonymous
September 02, 2008
@SPARTAN-117: other browsers render resources sent with "text/plain" as... plain text. IE is the only browser rendering text as HTML if it contains a whiff of (X)HTML. This can lead to some funky behaviors one way or another. It's too bad this opt-in parameter requires access to a server's "innards" (not all hosts allow use of local htaccess), because I don't think all hosts allow hosted websites to set up personalized (and proprietary) HTTP headers. But then, there aren't many other solutions... Tip: if you can, enable that setting for all hosted websites (and ask your ISP if he can do the same): you'll get a more uniform response across browsers and reduce debugging time. Personally I don't like having to add stuff to headers; but if everybody make use of it, then the setting may become opt-out for IE 9...Anonymous
September 02, 2008
The final Version of IE8 Will b drop on 1 Nov 2008 if beta2 is last beta milestone..!! chk this link.. https://support.microsoft.com/oas/default.aspx?LN=en-us&prid=12357&x=18&y=3Anonymous
September 02, 2008
Adding an extra header is just plain wrong. The other major browsers do not do this content sniffing on text/plain (any more, I do recall sites back when ns6 appeared where the css wouldn't work because of it) and there are no problems with sites that have incorrectly configured servers. This really only leaves intranet sites, which the company in charge of can easily fix. This seems to be the attitude with IE8 of lets add a header to tell IE8 to act the way it should in the first place. Stop it and make IE behave the way the standards say it should.Anonymous
September 02, 2008
I agree with David Knight. A browser should not sniff the content, it should look at the MIME type and honor it. A basic principle of security is to not trust third parties. You cannot rely on headers sent by a remote server. Malicious servers/scripts won't send the header anyway. Why display something as HTML when the server sent it as text/plain? That's just plain wrong. Moreover, this is yet another IE specific item. Doesn't make sense when you're claiming to move to web standards.Anonymous
September 02, 2008
Anyone on the IE8 team looking at Chrome today? Any comments on the fact that it seems to render Javascript 10x faster than IE8?Anonymous
September 02, 2008
"Any comments on the fact that it seems to render Javascript 10x faster than IE8?" The IE team already commented on other browsers being much faster, in this post: http://blogs.msdn.com/ie/archive/2008/08/26/ie8-performance.aspx Basically, they sarcastically point out how all browsers brag about their speed and performances, and say they will refrain from doing the same. To sum things up, IE has the worst performances among all modern browsers, but the IE team announce it proudly with an "holier than thou" attitude. But hey, at least IE8 is apparently faster than IE7, so it's a step in the right direction.Anonymous
September 02, 2008
The comment has been removedAnonymous
September 02, 2008
@david: Yes IE8 long way to go interms of Performance, web Standards. As Chrome drop today therefore more pressure is on IE Team for what they goin to deliver on final release of IE8. Chrome Pass 62/100 in Acid3 test But IE8 Beta2 only manage to pass 15/100 in Acid3 Test. This simply shows How far IE8 need to go. to be more web compliantAnonymous
September 02, 2008
Like many others, I believe sniffing should be an opt-in option, not an opt-out option. To avoid compatability problem, I suggest to the IE team to do what they have already done to the CSS expressions (bravo for that!):
- In IE8 mode (no X-UA-Compatible header), turn sniffing off.
- In IE7- mode (appropriate X-UA-Compatible set), turn sniffing on.
- If the X-Content-Type-Options header is set, follow whatever it says, regardless of compatibility mode (possible values being "sniff" and "nosniff"). This won't create a problem for legacy applications which would set X-UA-Compatible anyway, and it won't create a problem for intranet sites which run in compatibility mode by default.
- Anonymous
September 02, 2008
The comment has been removed - Anonymous
September 02, 2008
I agree that nosniff should be opt-out. If the IE8 team really feels they cannot do this, consider that: you could
- provide two options for the X-Content-Type-Options header: sniff and nosniff
- tell the world they should start specifying sniff for sites that require it
- announce that you're considering nosniff as default for IE9
- provide a registry switch that lets users turn their IE8 default to nosniff, so they can test whether all their sites that require sniffing have either been fixed or set to sniff that should at least give you some latitude for IE9.
Anonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
why isn't there a fast way to report bugs and suggestions built in the IE beta 2? I mean, isn't a beta about collecting as much feedback as possible?Anonymous
September 03, 2008
I agree with Vasil Rangelov. Content Sniffing should be OPT IN! in IE8 Standards Mode - No exceptions**! ** This means the IntERnet and the IntRAnet TOO MSFT. As for those commenting on Google Chrome... yes it completely smokes IE8 Beta 2 in any test you run... Standards, CSS, DOM, Speed, Parsing, Usability and most of all Coolness. IE's UI since version 7 has just been embarrassing.Anonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
That's IE6 on the picture, not IE7.Anonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
Will the authoritative asttribute still be supported or is it dropped in favor of the new header? I already implemented it here and there, so that's why I'm asking. And how hard is it for you to backport the new header to IE7 and perhaps IE6? It's an opt-in thing, should not break the web. Consider backporting some features of IE8 to increase acceptance.Anonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9113938&source=rss_news50 Would be interested in a post addressing this. Do you agree with the results? If not, why? If so, why did you make the tradeoffs you did?Anonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
speaking of java script performance... IE needs to have a JIT compiler for javascript like the one google built for chrome or the one mozilla is working on... It can't really be all that difficult for microsoft to achieve this can it? And it would stop everyone writing comments about IE's java script performance...Anonymous
September 03, 2008
Anybody know, when we will be available other languages?Anonymous
September 03, 2008
Content-Type: text/plain; IE8-DO-WHAT-I-JUST-SAID: please;Anonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
problems when the favorites star...crashes every timeAnonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
How do I turn off this "feature" where local INTRANET sites are not rendered by default in IE8 Standards mode (as they did in IE8 Beta 1) As a developer, EVERY site I DEVELOP is tested on my LOCAL network first, then deployed to an EXTERNAL site. Why the @#$%@! would I want to NOT have Standards mode turned on??? ARGHHH! I don't even get the darn broken page Icon so that I can fix what IE guessed incorrectly. I'm not liking this IE8 Beta 2 so far... please tell me that this INTRANET issue is getting fixed!Anonymous
September 03, 2008
Just can't wait for a working french beta :/ I've tested ie IIX on sbs 08 and looks great. ( °°)Anonymous
September 03, 2008
Justin, regaring your question: In the toolbar, click the Page icon, select "Compatibility View Settings", then uncheck "Display intranet sites in Compatibility View".Anonymous
September 03, 2008
Justin, regarding your question: In the toolbar, click the Page icon, select "Compatibility View Settings", then uncheck "Display intranet sites in Compatibility View".Anonymous
September 03, 2008
Although improved, the JavaScript console in IE really lacks a critical feature. a [CLEAR] button. I can't clear any previous errors to see if I've fixed an issue, or if it is repeatable. It would also be very nice if the console was tied to the URL 'javascript:' so that developers can pull it up just as they can/do in other browsers.Anonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
WOW Google chrome has a really nice download manager. Better than FF3 download manager. plz copy itAnonymous
September 03, 2008
I think that there should be a feature to automatically enable InPrivate browsing on certain sites, namely banking sites etc. This would improve security in several cases.Anonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
Wow, people seem to hate IE for no reason...Anonymous
September 03, 2008
when you place the favorite star before the tab it does not align vertically with the add to favorite bar star icon.Anonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
what I concern is Does IE 8 is faster than other(FF or Chrom),It not,I may not use itAnonymous
September 03, 2008
As I'm sure you've all heard, Google released a browser named Chrome. The thing I absolutely loved about their documentation (the comic they used to introduce it) was the way they test Chrome. Google uses their search engine to test their browser against the most popular websites. My suggestion to you? Use the same method! Contact the Live Search guys NOW and get cracking!Anonymous
September 03, 2008
Well, if I run this code inside IE8 beta 2: <div id="test"></div> ... t = document.getElementById("test"); while(true) { t.innerHTML += "a"; } It blocks the whole of IE, not just one tab. Everything becomes unresponsive. I thought IE8 was supposed to solve this problem? All tested browsers (Chrome, FF, Opera) deal with this better than IE8 beta 2.Anonymous
September 03, 2008
The comment has been removedAnonymous
September 03, 2008
"A browser should not sniff the content, it should look at the MIME type and honor it. A basic principle of security is to not trust third parties. You cannot rely on headers sent by a remote server. Malicious servers/scripts won't send the header anyway."</i> The MIME content type comes in the exact same type of header in the exact same HTTP response. Trusting one but not the other makes no sense.Anonymous
September 03, 2008
Someone made a pretty awesome list of <a href="http://www.dreamnut.com/greatest-web-hosting-disasters/"> web hosting FAIL. </a>Anonymous
September 04, 2008
The comment has been removedAnonymous
September 04, 2008
It is confusing that X-Content-Type-Options doesn't work in all cases. See http://lists.w3.org/Archives/Public/public-html/2008Sep/0084.html for an excellent description of the problem. Imagine that you allow users to upload documents to your website. For policy reasons, you require all images, stylesheets, and scripts to be screened before they can be published. In this situation, it would be nice to use X-Content-Type-Options to enforce that nothing can be interpreted as one of these types of documents unless explicitly labeled with the correct MIME type.Anonymous
September 04, 2008
It is confusing that X-Content-Type-Options doesn't work in all cases. See http://lists.w3.org/Archives/Public/public-html/2008Sep/0084.html for an excellent description of the problem. Imagine that you allow users to upload documents to your website. For policy reasons, you require all images, stylesheets, and scripts to be screened before they can be published. In this situation, it would be nice to use X-Content-Type-Options to help prevent other kinds of uploaded documents from being interpreted as one of these types of documents.Anonymous
September 04, 2008
I was bemused by the note that IE8 will render the no-sniff in plain text. It seems that "renders in plain text" will be the mantra for IE8 users. My XHTML5 page http://www.comfsm.fm/~dleeling/physci/ps83/t1.xhtml is rendered in plain text - as in code. Oddly enough, not only does FireFox and Opera render that page, but so does the brand new beta Google Chrome running on WebKit. How hard can this be? IE8 is the only major browser that cannot make some attempt at rendering XHTML5 with SVG and MathMl. To add insult to injury, it trashes my @media print id selector in my CSS and displays the @media print targeted CSS content on the screen. Good golly!Anonymous
September 05, 2008
Without commenting on the proposal itsef, one request / plea; please, please don't mint X-* headers. The (flawed) idea behind X- headers was that implementers could experiment (hence, X) with new mechanisms without worrying about conflicting with other header names. The problem is that as soon as that header name is used on the Internet, it is no longer experimental; it's in production now, and other systems have to interoperate with it, account for bugs in its various implementations, and so forth. So, the X- isn't helpful, it wastes bytes, and it's false advertising as soon as you actually use it. The only time it's appropriate to use it is when you're literally talking to yourself. If there's even the smallest chance that your header might one day be used with other systems, choose a real header field name, and register it, or at least tell IANA so they can put it in the header repository (see RFC3864, and feel free to ask for help). Thanks,Anonymous
September 06, 2008
Well i just want place this comment because of the fact i don't use IE anymore. Upgrades are very annoying, slow etc. I think it's good Google shows a browser what does what it's got to do. Wake up!Anonymous
September 06, 2008
forFar wrote: <button id="blah">Yay</button> button#blah{ height: 50px; } > Every browser on the mark would center the word "Yay" on the button of height 50px, except for IE8 This bug is new to IE8b2; it is listed in connect as Bug 365449 (https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=365449). > Could you please follow the standards on this sort of thing. Actually, there is no standard for this; HTML4.01 does not specify the /style/ of form elements, and CSS2.1 does not touch upon styling of form elements because such elements do not play well with the CSS display model in any current browser. (Incidentally, form elements are not the only ones in this category; BR and HR for example are also slippery characters.) That said, I couldn't agree more with your opinion; creating a new discrepancy here when there is already a /de facto/ standard followed by all other browsers (including previous version of IE) is very developer-unfriendly.Anonymous
September 06, 2008
[l] The second beta version of IE8 was released on August 27th. It is working well in testing so farAnonymous
September 06, 2008
The second beta version of IE8 was released on August 27th. It is working well in testing so far. OnlyAnonymous
September 07, 2008
In EVERY release of IE, Microsoft HAS to put some stupid, proprietary meta tags/headers support in his browser. Anyone here remember MSSmartTagsPreventParsing, MSThemeCompatible, ImageToolbar, Page-Enter, Page-Exit...? ...and, of course, X-UA-Compatible, X-Content-Type-Options etc Microsoft loves standards... ...they're own.Anonymous
September 09, 2008
"problems when the favorites star...crashes every time" Disable your buggy "Drive Letter Access" addon using the Manage Addons.Anonymous
September 12, 2008
Does IE8 loose/compromise on security features when IE8 is run in IE7 compatible mode (by adding meta tag in IIS or by clicking button within IE).Anonymous
September 12, 2008
@Prav: Essentially, no. The one thing is that in IE7 Compat mode, CSS Expressions can be used. The IE8 XSS Filter helps protect against attempting to exploit XSS vulnerabilities against CSS expressions, but it's still attack surface that's disabled in IE8 standards mode.Anonymous
September 16, 2008
a {color : #0033CC;} a:link {color: #0033CC;} a:visited.local {color: #0033CC;} a:visited {color : #800080;}Anonymous
October 16, 2008
Design criteria such as standard compliance, performance, reliability and security framed the designAnonymous
December 01, 2008
Back in June, Dean Hachamovitch kicked off a series of blog posts explaining how the IE team approachedAnonymous
March 16, 2009
    Internet Explorer 8  Beta 2 가 공개되어,  개발 팀에서 몇가지 최신 보안에 관한 소규모 변경에 대한 업데이트 정보를Anonymous
March 16, 2009
    Internet Explorer 8  Beta 2 가 공개되어,  개발 팀에서 몇가지 최신 보안에 관한 소규모 변경에 대한 업데이트 정보를Anonymous
March 18, 2009
IE8标准模式不再支持CSS表达式(Expression) 原文地址：EndingExpressions 标准遵守情况、性能、可靠性和安全性等设计标准构成了IE8的设计整体，包括新的和已经存在功...Anonymous
April 21, 2009
I attended Scott Charney’s keynote this morning at RSA – Moving Towards End to End Trust