EricLaw's IEInternals

Beware Silly Similes

EricLaw [MSFT] — Tue, 07 Feb 2012 17:44:00 GMT

Recently, there was a blog post which described a browser security feature as "like a seat-belt that snaps when you crash."

This wasn’t a particularly noteworthy event because similes are pretty common in our field. Almost everyone likes similes because they enable the simplification of highly technical topics into easily-conceptualized terms that anyone can understand. Similes are like JPEGs – they distill a big, complicated, intricate picture into a smaller (but still evocative) picture that bears some amount of resemblance to the original truth.

In our headline-driven culture, where subtlety and nuance don't draw the clicks that a quick witticism can bring, a great simile will spread across the web like pollen on a spring morning.

Of course, the downside¹ is that, like JPEGs, the compression is lossy. Important information can be obliterated in the conversion process. Technical experts might observe the loss, but an everyday consumer may not detect the difference. In some cases, that’s fine, but in others it really isn’t.

The problem with the simile in that recent blog post is that the information loss is unnecessarily high. The topic is complex, but that doesn't mean we can't use a simile—we just need to think a little harder.

Two more accurate similes immediately leap to mind. We could describe the security feature as

"Like a bicycle helmet that won’t prevent drowning if your boat sinks."

Or we could say it’s

"Like a flak jacket that can’t protect the lungs from chemical weapons."

Both of these are accurate statements that more closely reflect reality. They convey to the everyday person the nuance that the feature doesn't protect against all attacks—specifically, not those that it's not designed to protect against.

It's absolutely fair to wonder "Hey, why not develop a bike helmet that also acts as a life preserver?" Or, "Why not replace flak-jackets with MechWarrior-style exoskeletons that protect against a full spectrum of attacks?" These are legitimate questions, to be sure, but neither mistakenly suggests that bike helmets or flak jackets don't have their place in the world as it exists today.

The next time you hear a great simile, think carefully about what information its originator might have left out, and what motivations they may have had when crafting it.

-Eric

¹Of course, if you're the one trying to convince someone to buy or adopt something, the loss of information that contradicts your point of view is considered an upside, not a downside.

The Hazards of Browser Quirks, continued

EricLaw [MSFT] — Tue, 31 Jan 2012 16:47:00 GMT

My First Law of Browser Quirks was introduced a while ago: If there’s a way for a site to take dependency on a browser quirk, and break if that quirk is removed, it will happen. The Second Law of Browser Quirks is: If there’s a way for a site to combine a set of browser quirks to yield an entirely unexpected behavior, it will happen.

I was reminded of the Second Law a few weeks ago, when a site developer reported a bizarre behavior: namely, if they visited a page that was sent with Cache-Control: max-age=0 a few times, they’d see that the first HTTP/200 response was correctly cached, and then conditional requests would properly get HTTP/304 Not Modified responses. The developer then deleted that page from the backend, and they’d see a HTTP/404 correctly come back for the next revalidation request. However, if the developer renavigated to the page a few times quickly, the previously-delivered HTTP/200 page would sometimes be “magically resuscitated” from the local cache.

How, they wondered, could that possibly happen?

It was particularly strange because hitting the Refresh button would correctly show the 404 page.

Fortunately, I had just recently updated the Fiddler Caching Inspector, which examines a HTTP response to determine how it will be cached. A quick look at the Inspector led me to realize how this HTTP/404 page had yielded the unexpected result. Beyond specifying a Cache-Control: no-cache HTTP response header, the 404 page contained the following markup:

<meta http-equiv="Expires" content="0" />

Seeing caching directives in HTTP Markup always makes me a bit nervous, and it turns out that this is in fact the root cause of the problem. For historical reasons, Trident will respond to two directives in HTML markup:

<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="HTTP-DATE" />

No other directives (e.g. Cache-Control) are supported.

Each of the two supported directives, if encountered, causes Trident to call down to WinINET to adjust the HTTP caching freshness of the cache entry stored under the current URL. For the Pragma directive, if the current URL is HTTPS, Trident will call DeleteURLCacheEntry; if the URL isn’t HTTPS, it will instead call SetUrlCacheEntryInfo to adjust the time at which the document expires. For the Expires directive, the provided Date will simply be used as the new expiration time.

Now, Fiddler’s Caching Inspector points out one more thing: WinINET will never cache HTTP/404 response—it will only modify the cache if it receives a HTTP/200, HTTP/206, or HTTP/3xx redirect status code. Sending a caching directive in the HTTP/404 markup was unnecessary, because IE won’t ever cache that error page. That’s not to say that the META tag does nothing, however-- Trident doesn’t know (or care) that the document was sent with an uncacheable status code, and dutifully updates the expiration info for the existing cache entry—the HTTP/200 document that had originally been stored with in an expired state.

Half of the puzzle is solved, but why does Expires=0 result in the cache entry being deemed fresh? It’s especially surprising because if you send such an Expires directive using a HTTP header, the resulting cache entry will not be fresh.

If WinINET downloads a response with an invalid Expires header (e.g. one that doesn’t contain a valid HTTPDATE value) and no other caching directives, it will mark the document as having expired one hour ago. Trident, however, has no such logic. If you specify an invalid time, Trident grabs the current timestamp and uses that as the expiration. Trident will also use the current timestamp if it encounters the Pragma: no-cache directive. If the user tries to re-navigate to the current document during same exact second that the HTTP/404 was processed, the incorrectly-updated expiration of the existing cache entry will result in it being treated as fresh for that request. If the user hit the Refresh button or F5, the cache would be bypassed and the 404 page would be shown.

The solution for this website was pretty simple—either get rid of the unneeded META entirely (my recommendation) or update it to use a valid, long-ago HTTPDATE to avoid the incorrect update of the freshness info to the current timestamp. For instance, this markup:

<meta http-equiv="Expires" content="Sat, 11 Jun 2011 01:01:01 GMT" />

…results in the cached entry being marked as Expired.

Various bugs have been filed from this investigation, but my advice remains that web developers should do their very best to avoid specifying caching directives in markup.

-Eric Lawrence

Authenticode and Weak Certificate Chains

EricLaw [MSFT] — Fri, 19 Aug 2011 23:28:00 GMT

Recently, someone attempted to download a deprecated version of the Windows Script debugger. This tool was used to debug scripts prior to the introduction of more powerful, modern tools like those that are built into IE8 and later. The user emailed me when they encountered a very surprising outcome:

After clicking the Run button, the download proceeds, but then the user sees the message: <filename> was reported as unsafe.

The obvious question is “Who or what reported this file as unsafe?”

Many people might assume that this is a SmartScreen warning, but it’s not. When SmartScreen blocks a piece of known-malware, it takes all the credit, as you can see in this screenshot:

So, if it’s not SmartScreen, where is the warning coming from?

The answer is that the “<filename> was reported as unsafe” message occurs when the WinVerifyTrust API reports that there’s a problem with a downloaded file’s digital signature. Pretty straightforward. You’d might see this error if you tried to open an incompletely-downloaded file, for instance.

However… If you look at the signature in Windows Explorer, everything looks okay:

In particular, you’ll notice that the signature is marked OK at the top, and there’s a Timestamp at the bottom, which allows the signature to remain valid even after the certificate expires. However, that timestamp is twelve years old… this is a very old file.

Now, if you click the View Certificate button, and you’re a regular reader of my blog, you’ll might be able to spot the problem:

See it?

The problem is that the certificate itself is signed using the MD2 hash algorithm. This algorithm has known vulnerabilities and is not safe to use for untrusted content delivered over insecure networks. To that end, as I’ve mentioned in passing a couple of times on this blog, Internet Explorer 8+ on Windows 7 SP1+ no longer accepts Authenticode signatures that use the MD2 or MD4 hashing algorithms in the certificate chain. (MD2 and MD4 on the root itself isn’t a worry, because the root itself is installed on the machine). This restriction is enforced by passing the WTD_DISABLE_MD2_MD4 flag to WinVerifyTrust, instructing it to reject signatures that use either of these weak algorithms on the certificate chain. For the time being, Windows Explorer itself permits use of MD2 and MD4 in the signatures of locally-installed files, since the primary threat in today’s environment comes from code delivered using the Web.

In the real world, downloads that are signed using deprecated algorithms prove to be quite uncommon, because relatively few software vendors were signing their packages in the late 1990s when MD2 and MD4 were in use. We’ve identified a few ancient installers on Microsoft’s Download Center that will need to be removed or re-signed using current certificates and newer algorithms (e.g. SHA-1) to present a stronger defense against skilled attackers that might try to spoof a digital signature.

-Eric

Swapping out JQuery with Fiddler

EricLaw [MSFT] — Fri, 19 Aug 2011 22:22:00 GMT

This morning, someone asked me to look into a site-compatibility problem on a HTML5 demo site. When loading the site into IE9 and IE10, the F12 Developer Tools’ Script Debugger showed the following error:

Now, obviously, IE does support getElementsByTagName, and I confirmed that the page is running in IE9 and IE10 Standards Modes in each respective browser version. The next thing that stood out to me is the filename: jquery-1.5.min.js, which indicates that this is version 1.5.0 of the popular JQuery JavaScript library. Back in March, Tony Ross celebrated the release of JQuery 1.5.1 on the IEBlog, noting that 1.5.1 was the first version of the library to fully support IE9.

So, it looks like this site might be using an outdated version of the library. But is it the outdated library that's causing this script error, and is upgrading to the latest JQuery enough to make the site work properly?

In an earlier case, I had thought that a different site might have been broken because it was using JQuery 1.4.4, but the developer upgraded to the latest JQuery and it didn’t help-- it turned out that developer's code was doing a User-Agent check and bailing out if it saw MSIE.

So, before I got in touch with the owners of today’s demo site, I wanted to make sure that upgrading JQuery was all they needed to do.

Fortunately, Fiddler makes this task super easy. First, visit Jquery.com and download the JQuery library. If you plan on debugging into JQuery, get the Development version; since I’m hoping a simple upgrade will alone suffice, I downloaded the smaller minified version and saved it to my desktop:

Now, I booted Fiddler, and activated the AutoResponder tab. Using the Add… button, I created a new rule to map requests for JQuery-1.5.min.js to the newly downloaded jquery-1.6.2.min.js file I had just put on my desktop:

Be sure to set the Unmatched requests passthrough option to ensure that Fiddler doesn’t automatically generate 404s for requests that don’t match any of the rules.

Now, I went back to the site in IE and hit CTRL+F5 in the browser to force it to reload all of the content from the network. Fiddler intercepts the request for the older JQuery and returns the newer one instead. Fiddler shows the AutoResponse line in blue in the WebSessions list:

I was in luck-- with the new version of JQuery in place, the site ran correctly without any script errors, and the demo content worked beautifully! I could then confidently contact the site’s owner and request that they update their libraries, knowing that doing so will resolve the compatibility problem.

-Eric

HTTP Methods and Redirect Status Codes

EricLaw [MSFT] — Fri, 19 Aug 2011 18:14:00 GMT

This crossed my Twitter stream earlier today:

I’m not sure why we need a public service announcement to notify folks that Internet Explorer is behaving properly, but I guess there’s no harm in that. However, based on the lack of information provided, and the implication that this is surprising, I think the original actually poster meant to say something else.

So let’s explore this a bit. The HTTP/1.0 specification, RFC1945 describes HTTP/301 as follows:

301 Moved Permanently
The requested resource has been assigned a new permanent URL and any future references to this resource should be done using that URL.

// ...

Note: When automatically redirecting a POST request after receiving a 301 status code, some existing user agents will erroneously change it into a GET request.

The caveat in yellow also appears in the description for HTTP/302. Now, those “user agents” referred to in this remark included the popular browsers of the day, including Netscape Navigator and Internet Explorer. Arguably, this behavior is exactly what most websites wanted—after a successful POST, send the user to a different URL to show them something else. However, the POST-converted-to-GET behavior isn’t what the authors of HTTP had intended.

The authors of RFC2616 aimed to resolve the ambiguity by introducing two new redirection response codes in the HTTP/1.1 specification.

As noted inside the updated definition of HTTP/302:

Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

In defense of the implementers of the day, if RFC1945 and RFC2068 really do specify that the client user-agent is “not allowed to change the method”, they don’t do so in a very obvious manner. This expectation is not mentioned in the definition of the response code, nor is it mentioned in the preamble about redirects. Unfortunately, the current HTTPBIS Draft appears to suffer from the same limitation, although I believe that shortcoming is being tracked by a workitem in their list.

In RFC2616, the new HTTP/303 redirect code is defined thusly:

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource.

So, a 303 unambiguously means that the redirected request’s method should be changed to GET.

Unfortunately, the newly introduced definition of HTTP/307 failed to clearly specify that the original method was to be used-- the same problem that HTTP/302’s original definition suffered. However, it's obvious (based on the earlier text) that the intent of the HTTP/307 response code was to clearly indicate that the client should preserve the original method for the redirected request.

So, together, HTTP/303 and HTTP/307 allowed web developers to be specific about what they wanted to happen to the method (303->Convert to GET; 307->Keep original method).

Let’s see how well that has worked out...

Preserving Methods on Redirects

In this section, I’ll provide some cross-browser test results for a variety of scenarios. These are all generated using the XmlHttpRequest object and a Meddler Script file.

The MeddlerScript is as follows:

import Meddler;

import System;

import System.Net.Sockets;

import System.Windows.Forms;

class Handlers

    static function OnConnection(oSession: Session)

        if (oSession.ReadRequest()){

            var oHeaders: ResponseHeaders = new ResponseHeaders();

            oHeaders.Status = "200 OK";

            oHeaders["Connection"] = "close";

            var sRequestAsString = oSession.requestHeaders.ToString(true, true, true) + System.Text.Encoding.UTF8.GetString(oSession.requestBodyBytes);

            if (oSession.urlContains('redir'))

                MessageBox.Show(sRequestAsString, "Redirect Request");

                oHeaders["Content-Type"] = "text/plain";

                var s = oSession.GetQueryParams()["code"];

                oHeaders.Status = s + " redirect";

                oHeaders["Location"] = 'http://'+ oSession.requestHeaders["Host"] + '/final.cgi';

                oHeaders["Cache-Control"] = "max-age=0";

                oSession.WriteString(oHeaders.ToString());

                oSession.WriteString("redirecting...\r\n");

            else

            if (oSession.urlContains('final'))

                MessageBox.Show(sRequestAsString, "Final Request");

                oHeaders["Content-Type"] = "text/plain";

                oHeaders["Cache-Control"] = "max-age=0";

                oSession.WriteString(oHeaders.ToString());

                oSession.WriteString("Final Request was:<br />\r\n");

                oSession.WriteString(sRequestAsString);

            else

                oHeaders["Content-Type"] = "text/html";

                oSession.WriteString(oHeaders);

                oSession.WriteString("<html><head><title>XMLHTTPRequest-based Redirect Test Harness</title>\n");

                oSession.WriteString("<!doctype html>\r\n<html><head><script type='text/javascript'>\r\n");

                oSession.WriteString("var xmlHttp; var i=0;");

                oSession.WriteString("function doXHR(sMethod, sURI, sBody, iResponseCode){\r\n");

                oSession.WriteString("i++; xmlHttp = new XMLHttpRequest();\r\n");

                oSession.WriteString("\toutputdiv.innerHTML = '<pre>Beginning request #' + i + '...</pre><br />';\n");

                oSession.WriteString("\txmlHttp.onreadystatechange = stateChanged;\n");

                oSession.WriteString("\txmlHttp.open(sMethod,sURI+'?code='+iResponseCode,true);\n");

                oSession.WriteString("\txmlHttp.setRequestHeader('CustomHeader', 'CustomValue');\n");

                oSession.WriteString("\txmlHttp.send(sBody);}\n");

                oSession.WriteString("function stateChanged(){\n\t\nif (xmlHttp.readyState==4){\n data = xmlHttp.responseText; ResponseHeaders.innerHTML = '[#' + i + ']Script-accessible response headers were:<br/><PRE>' + xmlHttp.getAllResponseHeaders() + data+ '</pre>';}\n}\n");

                oSession.WriteString("function BuildRequest(){ doXHR(document.getElementById('txtMethod').value, document.getElementById('txtURI').value,document.getElementById('txtBody').value, document.getElementById('txtCode').value);\n}\n");

                oSession.WriteString("</script></head><body><br></p><hr>Output: <div id='outputdiv'></div><br>Response: <span id='ResponseHeaders'></div><br></span>");

                oSession.WriteString("<br /><input type=text id='txtMethod' value='GET' /><br />\n");

                oSession.WriteString("<input type=text id='txtURI' value='/redir.cgi' /><br />\n");

                oSession.WriteString("<input type=text id='txtBody' placeholder='Request body text...' value = '' /><br />\n");

                oSession.WriteString("<input type=text id='txtCode' value='302' />\n<br />");

                oSession.WriteString("<button onClick='BuildRequest();'>Send Request</button>");

                oSession.WriteString("</body></html>\n");

        oSession.CloseSocket();

In the first test, we examine HTTP/303 redirects:

IE 6-10	DELETE converted to GET
Chrome 13	DELETE converted to GET
Firefox 6	DELETE converted to GET
Safari 5.1	DELETE converted to GET
Opera 11.5	DELETE converted to GET

All browsers behave properly when receiving a HTTP/303 redirect code. Specifically, the client reissues the request after converting the DELETE method to a GET.

In the next test, we examine HTTP/307 redirects:

IE 6-10	DELETE method is preserved
Chrome 13	DELETE method is preserved
Firefox 6	DELETE method is preserved (after prompt)
Safari 5.1	DELETE method is preserved
Opera 11.5	Fails to redirect (after prompt)

All browsers (except Opera 11.5, which appears to be buggy) will correctly preserve the request method after receiving a HTTP/307.

Developers will run into cross-browser differences when using the older HTTP/301 and HTTP/302 methods.

IE 6-10	DELETE method is preserved
Chrome 13	Converts to GET
Firefox 6	Converts to GET
Safari 5.1	Converts to GET
Opera 11.5	Converts to GET

I believe that the highlighted result is what was surprising to the folks on Twitter. Only Internet Explorer avoids what RFC2616 calls "erroneous" behavior, by preserving the DELETE Method after the HTTP/302 redirection. Other browsers respond to a HTTP/301 or HTTP/302 as they do to HTTP/303, converting the method to GET.

But keep reading for another surprise...

This behavior mentioned in the last section was likely even more surprising because Internet Explorer does convert POST to GET for HTTP/301 and HTTP/302, like all other browsers:

IE 6-10	Converts to GET
Chrome 13	Converts to GET
Firefox 6	Converts to GET
Safari 5.1	Converts to GET
Opera 11.5	Converts to GET

As alluded to earlier, IE's POST->GET conversion for HTTP/301 and HTTP/302 is a historical artifact which was added in the 1990s for compatibility with the more popular web browsers of the time. Prior to the introduction of the XMLHttpRequest object, web pages could not really make use of other HTTP methods, which is why the method conversion is scoped to just the POST method.

Notably, browsers also behave differently in handling a 302 response to a HEAD request:

IE 6-10	HEAD method is preserved
Chrome 13	HEAD converts to GET
Firefox 6	HEAD converts to GET
Safari 5.1	HEAD converts to GET
Opera 11.5	Redirect is not followed

It seems like the unexpected conversion of HEAD into GET could lead to performance problems or functionality bugs.

Confirming Redirects

Now, RFC2616 also notes that redirects generally shouldn’t happen “automatically” except for idempotent / “safe” methods; the idea being that the user should have to confirm performing the same action on a different URL. In practice, a user is unlikely to have any idea what the prompt means, and thus most browsers ignore the requirement to confirm the redirection with the user.

Browser Behavior on Warn on POST –> 307 Redirect

IE 6-10	Silent re-post
Chrome 13	Silent re-post
Firefox 6	Prompts (no target URL) before reposting
Safari 5.1	Silent re-post
Opera 11.5	Prompts (with target info) but neither Yes nor No results in a request. Bug?

Firefox's redirect confirmation prompt:

Opera's redirect confirmation prompt (note: Doesn't seem to matter which of the three buttons you click)

I hope this helps clear things up. In general, if you're using any method other than GET and you want to redirect, use HTTP/303 and HTTP/307 to be very explicit about what you want to have happen.

-Eric

Sharpen the Saw

EricLaw [MSFT] — Mon, 15 Aug 2011 00:55:00 GMT

Gather round, young’ins, Grandpa Eric is going to tell you a story.

Back in the old days, when I started writing software, programmers’ utilities were sold in boxes in retail stores. You’d plunk down your 149 bucks or whatever (in cash, kids, this was before credit cards got popular) and you’d get your cardboard box full of floppies (or maybe a CD, if you were cutting edge) and a manual. If you wanted to save a few bucks, you might hunt for a paper catalog or classified ad in a programmer’s journal and find a mail-order house to order from. You’d fill out a form, enclose a check, and wait a few weeks to get your box.

Now, when I say you got “a manual”, I’m talking about the real deal, a book a few hundred pages long, crafted with care to explain how to make use of what you’d bought. This wasn’t at all like what you get today if you happen to buy software that ships from Amazon or whatever, which usually consists of a little leaflet of disclaimers written by the lawyers, and maybe a little picture showing how to put the CD in the computer. Nor was a good manual like most of today’s online help files, which consist of what seem to be printouts of the functional spec. No, you got a book, which was thorough and written with the expectation that it would be read. The chapters would be logically organized, and usually included more than just the basics, giving examples, tips, and oftentimes, some little jokes or other signs that a human being was actually involved in the production. A good manual reinforced the developers’ pride-of-craftsmanship—if it was too awkward to write an explanation of how to use a feature, the embarrassed developers would be forced to redesign the feature, if only to allow the manual to pass the giggle-test.

Things have changed in the last 15 years. These days, you just launch your browser and download your indispensible utilities, free of charge, in less time than you’ve spent reading so far. But something was lost in this paradigm shift, which is why I was so excited to hear that the legendary Mark Russinovich had teamed up with all-around-smart guy Aaron Margosis to put together an honest-to-goodness book, a guide to the Sysinternals toolset. Titled Windows Sysinternals Administrator’s Reference, can get it for your Kindle, or as I did, in old-fashioned dead-tree format, suitable for scribbling in and dog-earing to your heart’s content. I’ll admit that the title had me a bit worried (I don’t want to administer anything, really), but I’m guessing that their publisher wouldn’t let them name the book more aptly (e.g. “Using Sysinternals Tools to Demystify Shi^H^Hoftware”)

Now, for the rare techie who’s not already a big fan of the Sysinternals tools, I’ll give a bit of background. The collection includes around 70 freeware utilities grouped into six loose categories (Process Utilities, Security Utilities, File and Disk Utilities, Networking Utilities, System Info, and Miscellaneous) the majority of which run on any version of Windows (XP and later). I’ve been using several of the tools on an almost daily basis for a decade. I use Sysinternals utilities to deeply understand the guts of every product I’ve ever worked on, and to resolve problems with many pieces of software I otherwise know little about..

One of the perks of working in the Windows division at Microsoft is access to the source code of every version of Windows we’ve shipped in the last decade, but when I want to understand how our software works, I turn to Fiddler and the Sysinternals tools. Why? Because these utilities tell you the truth and show what’s really going on. Source code is super-useful, of course, but it’s often much more challenging to dig through—there are tens of millions of lines of code to sift through, and they interact in ways that were never formally documented, and sometimes, we find, ways that were never intended. The advantage of using monitoring utilities is that you get to see what’s happening, and that usually brings you 90% of the way to a solution. The ability to “peek inside” software as it runs is astonishingly empowering-- in the same way that xrays and MRIs have had a huge impact on the practice of medicine.

Just booting Fiddler or Process Monitor and watching the events fly by will provide a non-trivial level of insight into how software on your computer works. But there’s a difference between toying with these utilities and fully exploiting their power, and this is where Mark and Aaron’s new book comes in. The book covers each of the tools and provides a full explanation of each; the two most useful tools (Process Explorer and Process Monitor) each get a chapter all their own, but even the most trivial of the utilities in the collection gets a page of coverage.

As a developer myself, my favorite parts of the book are where the authors reveal some of the tools’ “secrets”, explaining how they accomplish some interesting task. For instance, Process Explorer can be configured to replace the native Windows Task Manager—a non-trivial exercise unless you know the clever trick of using Image File Execution Options to remap one executable to another. Similarly, the “Jump To Registry Key” feature used throughout the suite simply relies on sending keys to the Registry Editor window, and is thus subject to the same UIPI restrictions that prevent Low Rights IE add-ons from sending input to medium integrity applications. Lastly, I learned how the ps* Utilities are able to deliver their functionality to remote systems, despite the seeming impossibility of that task.

My other favorite parts of the book are the “Case of the…” sections that comprise the last three chapters—each section explains how the authors (or their colleagues) have used one or more of the Sysinternals tools to solve a real-world problem. These sections are well-written, super-interesting, and provide a fantastic primer for turning what you’ve learned in the earlier chapters into real-world results.

The book includes tons of facts about Windows itself that I’d forgotten or never picked up on to begin with. For instance, over the last half decade I’ve wondered about the “phantom” C:\Documents and Settings\ folder on Vista+ machines. I correctly guessed that the folder was still there for legacy compatibility reasons, but didn’t understand how it enhanced compat, since attempting to navigate to the folder somehow fails. Thanks to the book, I now know that this is a NTFS Junction pointed at C:\Users, but it is configured to deny the List Files permission while allowing all other permissions. In this way, a legacy application can read or write a specific file inside C:\Documents and Settings\, while blocking the user from explicitly navigating into that path. Similarly, I learned that the 32bit “WOW64” subsystem can be uninstalled on the Core SKU of Windows Server, an interesting configuration tidbit for developers of any tool that includes 32bit components.

Over the years, Windows has added a number of features previously only available in the Sysinternals tools—the authors mention when this is the case, and compare and contrast the new Windows features to those in the Sysinternals utilities. For instance, on Windows 7, the command powercfg /energy (see pg 375) generates a super-interesting report that I didn’t even know existed.

No book is perfect, of course. The book’s structure enables the reader to jump directly to information about each specific tool, so anyone who reads the book cover-to-cover as I did will find some repetition of information between the sections and chapters. The authors’ expectations of their readers’ technical-savvy also seems uneven at some points—I was amused that a book that discusses kernel debugging and memory-manager design would take the time to footnote the meaning of the word “string” as it is used in software. But, on the whole, the book is very well-written.

As of this writing, the Windows SysInternals Administrator’s Reference will set you back less than thirty bucks and it’s worth every penny—heck, you could probably buy the EBook and a Kindle for less than this class of product would have sold for in the 1990s. Sure, you can just download the tools for free, but I guarantee you’ll get more out of them if you read the book. If you develop or debug software on the Windows platform, this book will provide a great return on investment (purchase price and reading time).

-Eric Lawrence

Internet Explorer 9.0.2 Update

EricLaw [MSFT] — Fri, 12 Aug 2011 18:56:00 GMT

Tuesday’s Update for Internet Explorer updates the IE9 Help > About dialog’s version number to v9.0.2. The update includes a number of security and functionality fixes; many of these fixes are described in the More Information section of KB2559049. One fix enables the IE9 Download Manager to properly save files on network drives where the user has limited permissions. Another fix helps ensure that IE8 can properly access sites that advertise IPv6 addresses when those sites are not reachable over IPv6 due to configuration errors on the site or the user’s network.

Two of the security-related changes impact obscure Internet Explorer behaviors in all supported browser versions (IE6 to IE10) -- I’ll discuss both of these changes in this post.

New restrictions on use of the file:// Protocol

Prior to this update, Internet Explorer would allow non-file-protocol (e.g. HTTP and HTTPS)-delivered pages to frame (e.g. using an IFRAME) or navigate to pages that were delivered using the file:// protocol scheme. IE would only block loading of resources from the local computer (e.g. file:///C:/temp/test.gif), but resources from non-local paths would be allowed. Here’s an example page displayed in IE 9.0.1:

And here’s the same page loaded into IE 9.0.2:

Other browsers have blocked cross-protocol interactions for quite some time. Here are screenshots of the Firefox 5, Chrome 14, and Opera 11.5 developer consoles in this scenario:

By default, this new restriction only applies to iexplore.exe and explorer.exe (to support Windows XP). This restriction applies only to pages running in the Internet and Restricted Sites Zones.

We do not expect significant compatibility impact from this change, as no popular sites in the affected Zones rely upon the ability to pull in file://-sourced content. In the event of an problem, the user may add the HTTP/HTTPS site to the Trusted Sites zone and the file-protocol-sourced content will load as it did prior to this update.

Cookie Filenames are Randomized

As a rule, Internet Explorer attempts to prevent Internet sites from storing content in predictable locations on the local computer, in order to foil a number of attack types. That rule is why, for instance, the Internet-cache stores content in randomly-named subfolders.

Prior to this update, Cookies were an exception to this behavior—their location was insufficiently random in many cases. Generally, cookie files were stored under the \AppData\Roaming\Microsoft\Windows\Cookies folder, in files named using the user’s login name, an@ symbol, and a partial hostname for the cookie’s domain:

Given sufficient information about the user’s environment, an attacker might have been able to guess the location of a given cookie and use this information in a multi-stage attack.

To mitigate this threat, Internet Explorer 9.0.2 now names the cookie files using a randomly-generated alphanumeric string. Cookies are not instantly renamed on upgrade, but are instead renamed as soon as any update to the cookie’s data occurs. You can see the impact thusly:

We do not expect significant compatibility fallout from this change either, as the names of these files have always been somewhat dynamic. Directly enumerating or reading the Cookie files has never been supported. Instead, local applications that wish to interact with cookies can use the InternetGetCookieEx and IEGetProtectedModeCookie APIs, or they can use the WinINET cache-enumeration functions.

-Eric

Please don't make XHR run in synchronous mode

EricLaw [MSFT] — Wed, 03 Aug 2011 22:47:21 GMT

8.4% of all hangs in IE9 in the past month are caused by XMLHttpRequest objects blocking the UI thread with a synchronous request.

http://blogs.msdn.com/b/wer/archive/2011/08/03/why-you-should-use-xmlhttprequest-asynchronously.aspx

If your page uses XHR in synchronous mode, your first thought should be "I'm doing something wrong."

Default Integrity Level and Automation

EricLaw [MSFT] — Wed, 03 Aug 2011 16:42:00 GMT

Over on StackOverflow, danimajo asked for help in an interesting scenario. Basically, he’s trying to drive Internet Explorer through automation, but finds that when he navigates to an Intranet site, the hidden browser instance appears and he can no longer control it. What’s going on?

Background on Protected Mode

Internet Explorer’s Protected Mode is a security sandbox that relies upon the integrity level system in Windows. A process may have only one integrity level (IL), so if you navigate an IE instance between a Internet (Protected Mode, LowIL) and Intranet (non-Protected Mode, MediumIL) site, Internet Explorer must handle the navigation in a new process. In IE7 on Vista, this was very visible—a new browser window would open automatically. In IE8, with the introduction of Loosely-Coupled IE (LCIE), we can handle this more subtly.

Background on Loosely-Coupled IE

In LCIE, IE always has at least two processes—the browser Frame Manager process (which always runs at MediumIL unless you start IE as admin) and one or more browser Tab Content processes, which run at:

LowIL for Protected Mode sites
MediumIL for Intranet/Trusted sites
HighIL (if IE is started as Admin)

Because the Frame Manager process can “visually” host tabs of any integrity level, if the user navigates a page from a LowIL zone to a MediumIL zone, the Frame Manager process can silently swap out the current tab process with a tab process running at a different integrity level. This operation is called a “Virtual Tab switch.”

Losing Control

For compatibility with the most likely scenarios, Internet Explorer assumes that the default tab process will be a Low Integrity tab. Hence, when Internet Explorer is created by COM Automation, the tab process defaults to a Low Integrity tab. If the browser determines that the navigation requires a Medium Integrity Tab Content process, a virtual tab switch is performed. Now, here’s where things get interesting—because the script or code driving Internet Explorer via Automation has a reference to the now-irrelevant tab process, it loses control.

Regaining Control

Now, it’s possible for the caller to handle this situation, by trapping the NewProcess event and reacting accordingly. However, this requires a fair bit of code, and in some cases it might be desirable for an automation caller to simply evaluate its own needs (e.g. it is only configured to navigate to Intranet pages) and invoke an instance of Internet Explorer running at MediumIL to start with. In languages like C++ and C#, this is easy, just CoCreate an instance of CLSID_InternetExplorerMedium ("{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}"). When using this CLSID, the object will default to a MediumIL Tab Content process. How this works under the covers is pretty simple: the registry key HKEY_CLASSES_ROOT\CLSID\{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}\LocalServer32 contains a REG_EXPAND_SZ with the value "%ProgramFiles(x86)%\Internet Explorer\iexplore.exe" -startmediumtab

Unfortunately, as far as I can tell, there’s no way for scripting languages like VBScript or JavaScript running in CScript or WScript to pass a CLSID into CreateObject—it only accepts a ProgID. UPDATE: WndSks noted in the comments below that you can use the syntax Set IE = GetObject("new:{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}")

There’s no ProgID that maps to CLSID_InternetExplorerMedium, but you can trivially create one with a simple registry update.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\InternetExplorer.ApplicationMedium]

[HKEY_CLASSES_ROOT\InternetExplorer.ApplicationMedium\CLSID]
@="{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}"

After that, you can invoke a MediumIL instance of IE from script like so:

Set IE = CreateObject("InternetExplorer.ApplicationMedium")
' IE.Visible = false ' This is the default
IE.Navigate2 “http://intranetpage/”

So long as you navigate this instance only to pages that run outside of Protected Mode, your automation code will not lose its reference and the Internet Explorer window will remain invisible, unless you explicitly change the visible property.

-Eric

Best Practice: Get your HEAD in order

EricLaw [MSFT] — Mon, 18 Jul 2011 21:06:00 GMT

To ensure optimal performance and reliability when rendering pages, you should order the elements within the HEAD element carefully. First, I’ll explain the optimal order, and then explain the reasoning for this structure.

Optimal Head Ordering

<doctype>
    <html>
        <head>
            <meta http-equiv content-type charset>
            <meta http-equiv x-ua-compatible>
            <base>
            <title, favicon, comments, script blocks, etc>

Why Order Matters

In order to understand why the ordering of the elements in the HEAD matters, it’s important to understand how the browser parses webpages, and what impact each element has on the parsing of the page.

When the browser begins parsing a page, it begins reading the bytes of the HTTP response body. If the response’s Content-Type header specifies a charset attribute, those body bytes can immediately be interpreted as text using the specified character encoding. However, if a charset declaration is not present, the browser must begin scanning the bytes of the response body, checking for a Unicode Byte-Order-Marker at the top or scanning for a META HTTP-EQUIV element that specifies the charset. When such a declaration is reached, the parser may need to restart in order to ensure that the bytes previously read were interpreted properly. When a restart occurs, the F12 Developer Tools will show the following note in the console:

This restart can impact performance, as we’ll discuss momentarily.

If a character set declaration is not found, the browser is forced to “Autodetect” the content-encoding based on the nature of the bytes read or other factors, potentially resulting in a mismatch between the web developer’s intent and the browser’s guess. That mismatch can result in a broken page, or a page which contains gibberish in some places. Therefore, for functionality and performance reasons, it is a best-practice to specify the encoding^[1] using HTTP response headers. If you must specify the character set using a META tag for some reason, it is critical that the META tag is the first element in the HEAD.

Internet Explorer 8 and later versions allow page authors to specify which document mode should be used for the rendering of the page, in order to enable a site to suggest that later versions of IE should render a given page in a legacy mode for compatibility reasons. Because the document mode can impact how the browser parses a page, Internet Explorer will need to restart the parsing process if a META element is found that specifies an X-UA-Compatible value different than was originally used to start parsing. The F12 Developer tools will note when a restart was needed:

For that reason, it is a best-practice to specify any X-UA-Compatible value as a HTTP response header. If you must specify the X-UA-Compatible value using a META tag for some reason, this element MUST appear before any script blocks and SHOULD appear as early in the HEAD element as possible. In some cases, a specified X-UA-Compatible META tag can be ignored (e.g. because the document mode was already finalized due to earlier markup^[2]). When this happens, the F12 Developer Tools’ console will show the following message:

The BASE element controls how any relative URLs in your page are made absolute in order to retrieve the specified resources from the network. Ordinarily, a relative URL is combined with the URL of a page in order to make it absolute. However, when a BASE tag is present, the specified HREF is used for URL-combination, and the page’s URL is not used. Because the BASE element impacts the combination of all relative URLs in a page, it MUST appear before any relative URLs in your page. As of IE7, the BASE element MUST appear within the HEAD element and will be ignored if it appears in the body. While it is technically possible to use JavaScript (e.g. via document.write) to specify a BASE element, doing so is strongly discouraged.

After you’ve specified any of the charset, X-UA-Compatible, and BASE declarations you need, finish out your HEAD tag with a TITLE element and any other markup.

Understanding the Lookahead Pre-parser

To reduce the delay inherent in downloading script, stylesheets, images, and other resources referenced in an HTML page, Internet Explorer needs to request the download of those resources as early as possible in the loading of the page. The key problem is that the browser’s parser must pause when it encounters a non-async/non-defer script element, in order to run the script in order, as required by the standards. In the absence of mitigations, this pause would result in a significant delay in the parsing of the rest of the page, and thus result in resources being requested from the network much later.

To mitigate this issue when loading a page, Internet Explorer runs a second instance of a parser whose job is to hunt for resources to download while the main parser is paused. This mode is called the lookahead pre-parser^[3] because it looks ahead of the main parser for resources referenced in later markup. The download requests triggered by the lookahead are called “speculative” because it is possible (not likely, but possible) that the script run by the main parser will change the meaning of the subsequent markup (for instance, it might adjust the BASE against which relative URLs are combined) and result in the speculative request being wasted.

Critically, when the parser is forced to incur a document mode or charset restart, IE aborts all of that page’s in-flight requests and begins parsing of the page anew, again looking for resources to speculatively download. Beyond the CPU cost of these restarts, there can be a network cost as well.

For instance, consider a page that restarts from IE9 Standards mode to Quirks Mode. The F12 console shows the restart:

…and you can see the aborted speculative requests listed in the Network tab of the F12 Developer Tools:

Because the restart occurs very early on in page load, only the first speculative request actually made it through URLMon and WinINET and was requested from the network.

In Fiddler, you can see the aborted request for /1.js. The Reason column shows that the first request was from the original html lookahead tokenizer while the subsequent (successful) downloads were triggered by the restarted html lookahead tokenizer:

Because the browser aborted the first request for the script file, it didn’t read the entire response from the network; instead it issued a TCP RST on the request’s connection, immediately closing it. When the restarted lookahead identified the same resource to download, it required the establishment of a new TCP/IP connection.

For best performance, specify your page’s character set and X-UA-Compatible (if desired) using HTTP response headers, helping the browser avoid expensive restarts.

-Eric

^[1]In case you’re wondering, UTF-8 encoding is the best choice. For web content, UTF-8 is almost always more efficient than UTF-16, and there are some peculiarities with UTF-16 support that make it inadvisable for use in web content.

^[2]Internet Explorer 10 PPB2 introduced a new architecture where a versioning pre-scan occurs before the parsers begin their work; the X-UA-Compatible META tag must appear in the first 4kb of the markup or it will be ignored.

^[3] Regular readers may recall that I’ve written about Internet Explorer’s Lookahead downloading feature previously.

Understanding Protocols

EricLaw [MSFT] — Thu, 14 Jul 2011 01:21:00 GMT

For over a decade, Internet Explorer has enabled developers to extend the browser with new URL protocol schemes. These protocols can be one of two types:

Asynchronous Pluggable Protocols - COM objects that implement the IInternetProtocolRoot interface and return content to URLMon, usually for rendering content inside of Internet Explorer or Web Browser controls
Application Protocols - launch a program outside of Internet Explorer when invoked.

In today’s post, I’ll explain the difference between these two protocol types, and share what I’ve learned about them over the years.

Asynchronous Pluggable Protocols

Pluggable Protocols include the http, https, ftp, and file protocols, and many less-common ones. This type of protocol can be registered at runtime by a browser extension, but most “permanent” protocols are registered inside the HKCR\Protocols\Handler registry key, as you can see in the screenshot below:

When Internet Explorer (or the web browser control) encounters a URL whose protocol scheme is registered in this key, URLMon will create the COM object specified, pass in the URL provided, and begin to read data from the protocol handler object. Because support for Pluggable Protocols is implemented by URLMon, typically only IE-derived browsers (e.g. IE, Maxthon, etc) are able to load Pluggable Protocols. Other browsers offer similar proprietary mechanisms for implementing custom protocols.

Writing an Asynchronous Pluggable Protocol is an extremely challenging exercise – beyond being complex to implement, they are very often the target of hackers. That’s because permanently registered protocols can be freely invoked by any webpage and malicious input (e.g. a malformed or over-long URL) can be passed into the implementation of the Start method. In some cases, cross-site scripting (XSS), script-injection, or cross-site request forgery (CSRF) attacks can be conducted against these protocols. Because the browser accesses Pluggable Protocols asynchronously, and using multiple threads, and navigations can abort downloads at any time, object lifetime issues are prevalent. The IE team often first learns about a new Pluggable Protocol when we see a flood of crashes reported to Watson or learn about active exploits of vulnerable protocols by bad guys.

Developing an Pluggable Protocol is far beyond the scope of this article, but if you want a quick look, check out this simple Pluggable Protocol example on CodeProject—it shows how you could implement support for Data URIs before they were built into IE8. There’s a similar example written in C# which you can find here, with the caveat that you should never try to develop “production quality” IE extensions (protocols, BHOs, ActiveX controls, toolbars, etc) in .NET because of the performance and stability problems that inevitably result.

Application Protocols

In contrast to Pluggable Protocols, Application Protocols are much simpler. Rather than returning content to the browser, they simply enable the browser (or another program like a word processor or PDF reader) to launch a program, passing the requested URL to that program. Common examples of Application Protocols include the mailto:^[1] news:, and onenote: protocols.

Application Protocols are conceptually simple—a protocol scheme (e.g. onenote:) is associated in the registry with a locally installed application (e.g. onenote.exe). The association is created by adding a new REG_SZ named URL Protocol inside the key HKCR\<protocolscheme>\.

The invoked URL is injected to replace the %1 parameter in the registered \Shell\Open\Command:

Thanks to their simplicity, and to the fact that the Windows ShellExecuteEx function can easily be used to launch such protocols, all major Windows web browsers (IE, Firefox, Chrome, Safari, Opera) support Application Protocols. However, there are some important differences in behavior between browsers.

The first thing to understand is that despite their simplicity, Application Protocols have nevertheless been the source of a large number of vulnerabilities over the years, and thus nearly all browsers (except Safari) will prompt the user before launching the specified program.

Internet Explorer 8+ (and Web Browser Controls that opt-in to FEATURE_SHOW_APP_PROTOCOL_WARN_DIALOG) will show the following prompt:

The user may control whether this prompt appears by unticking the Always ask before opening this type of address box; the decision is stored inside a REG_DWORD named WarnOnOpen inside HKCU\SOFTWARE\Microsoft\Internet Explorer\ProtocolExecute\; the default value is 0x1, which enables the warning, and the value 0x0 disables the warning. The HKLM version of this key is also respected in the event that the administrator or application developer has set the policy on the user’s behalf, but for security reasons suppressing this prompt is generally discouraged.

Other browsers show similar prompts, which you can see here:

In Internet Explorer 7 and later on Windows Vista and later, launching an application to handle an Application Protocol URL will also consult the Protected Mode Elevation policy for the target executable. By default, this policy is that the user will be prompted for permission to launch the program at the Medium Integrity Level:

You can learn more about Protected Mode Elevation policy by reading my previous blog post on that topic.

Many vulnerabilities in Application Protocols stem from the fact that developers often try to quickly “bolt on” support for this feature into their existing programs. This is frequently a source of security bugs because many programs are not written with the expectation that untrusted data (e.g. the web-supplied URL) will be passed in on their command line. Vulnerable programs often have simple logic bugs (e.g. buffer-overflowing because they fail to handle command line arguments larger than some fixed size) but some have more complicated problems. For instance, some programs will immediately undertake a permanent configuration change without first confirming it with the user. For example, one buggy implementation I once saw would immediately delete user data when passed a particular command line argument—the command to do so existed for many years before a later developer came in and quickly added the code to expose the program as an Application Protocol handler without performing an analysis of the threats posed by untrusted arguments.

Another behavior to be aware of is that some callers will decode or encode URLs before passing them along to the target program. For historical reasons, Internet Explorer performs a single percent-decoding pass on the URL before calling ShellExecute; by default IE9 and IE10 still perform this decoding unless the protocol’s registry key contains a REG_DWORD named UseOriginalUrlEncoding with value 0x1. However, the Windows Shell’s Start > Run command performs no such decoding pass.

The following image shows the behavior in four different scenarios when invoking the URL alert:Escaped%22Quoted%22and"UnescapedQuoted" to launch a trivial program.

Detecting Installed Protocols

Web developers often ask if there’s some way to detect whether the client has a given protocol available. Generally, the answer is no, this isn’t possible. In IE, if a page attempts to navigate to a protocol which is not registered, the user will see the following notification page:

Opera and Safari show a similar page, while Firefox shows a modal error alert, and Chrome will simply fail the navigation. Only Firefox fires an OnError event when a navigation is attempted to an unregistered protocol.

Unfortunately, that means that there is no cross-browser, standardized method to detect whether the user’s browser can invoke a particular protocol. In the past, some setup programs would try to inject a token into the user’s User-Agent string or add a Version Vector (see the same article) that a web page can detect. Alternatively, some packages include both a protocol and and ActiveX control—the ActiveX control only exists to enable the web page to infer whether or not the Application Protocol is installed. All three of these methods have significant downsides, and none of the three approaches will work in non-IE browsers.

-Eric

^[1]Technically speaking, IE includes some special-case code for mailto that makes it behave a little differently than most Application Protocols. But it’s pretty close.

Integrated Windows Authentication

EricLaw [MSFT] — Wed, 06 Jul 2011 20:58:00 GMT

Inside Internet Explorer’s Tools > Internet Options > Advanced dialog, there’s an option named Enable Integrated Windows Authentication:

This preference is stored using a REG_DWORD named EnableNegotiate inside HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings. When set to 0x1, Negotiate is enabled.

From time to time, users have asked what this option does and why they’d ever want to adjust it. The answer is that the Integrated Windows Authentication (IWA) option controls whether Internet Explorer (and applications based on WinINET) will use the Negotiate authentication protocol to respond to HTTP/401 challenges from servers. At a high-level, Negotiate is a “wrapper” around the Kerberos and NTLM authentication protocols. If Kerberos can be used, it will be, otherwise the Negotiate protocol will use NTLM. If you disable the IWA protocol, then a HTTP/401 challenge which only offers Negotiate will be treated as “final” and the client will refuse to authenticate.

Most servers are configured to return a challenge which offers both Negotiate and “unwrapped” NTLM, such that if the user has disabled Negotiate by unticking the IWA checkbox, the client will still be able to authenticate using the NTLM protocol:

Fiddler’s Auth inspector tabs will show you what authentication protocol is in use:

…and when NTLM is in use, it will even break down the authentication blobs into a textual explanation:

IWA is enabled by default and generally should be left that way. However, for troubleshooting purposes, it is sometimes useful to disable the option (don’t forget to restart all IE instances) to see whether a given authentication problem may be related to the use of Kerberos.

For instance, some users have encountered problems where a given server returns a HTTP/400 error when IWA is enabled:

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Wed, 06 Jul 2011 20:48:07 GMT
Connection: close
Content-Length: 346

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Request Too Long</h2>
<hr><p>HTTP Error 400. The size of the request headers is too long.</p>
</BODY></HTML>

If IWA is disabled, then NTLM is used and the request succeeds. The problem in this case is that many IIS servers are configured to refuse HTTP requests that contain more than 16kb of header information. A Negotiate authentication string contains a base-64-encoded Kerberos ticket which includes a list of all of the security groups to which the current user belongs. In some environments this list can grow quite large and hence the client’s Authorization header alone exceeds the 16kb limit. When IWA is disabled, NTLM is used instead and the smaller Authorization token does not exceed the configured limit.

A member of the IIS Team wrote a blog further explaining this issue, including steps to see how many groups you belong to. IIS servers can be configured to allow larger HTTP requests, which works around this problem without reconfiguring the client or trimming the user’s group memberships. Servers can also be reconfigured to permit connection-based Negotiate authentication which lowers the performance impact of sending large Kerberos tickets on every request. You can also read this KB.

-Eric

The Perils of User-Agent Sniffing, 2011 Edition

EricLaw [MSFT] — Thu, 30 Jun 2011 01:35:00 GMT

I continue to be amazed at how often site-compatibility issues turn out to have a root cause related to User-Agent sniffing.

For instance, earlier this year, someone wrote into the comments section on one of my posts noting that the HTML5 canvas art site WeaveSilk.com wasn’t working in IE9. After reading through thousands of lines of JavaScript, including various libraries, I found the culprit at the very end of the page, which you can see here, along with the very simple fix:

Simply put, if the browser’s UA string contained “MSIE”, the site skipped all of its initialization code. Oops.

Today, I encountered two more issues of this class of problem. One is with the Google Fonts site. By default, if you load this site, you’ll find that it’s blank and contains no content:

A quick peek in Fiddler shows that the problem is that the server is returning HTML pages with an “Your browser is unsupported” message when IE attempts to download the CSS and JS for the page.

If you use the F12 Developer Tools or Fiddler to change the User-Agent string, then the site returns correct content and the page loads correctly:

Because the Google.com domain is on the Compatibility View list, the site is in IE8 Browser Mode by default. You can see this on a Google page by pressing F12 to see the Developer tools; the Browser Mode is IE8: . While the page itself can select a later Document Mode using an X-UA-Compatible meta tag, the User-Agent string is selected by the Browser Mode, not the Document Mode. The distinction between these two modes is often misunderstood—there’s a great MSDN Article which explains the difference between the Browser Mode and Document Mode settings.

The second UA-string issue I encountered today was closer to home. Eagle-eyed viewers of the high-resolution video included in the blog post announcing the IE10 Platform Preview 2 might have observed that the text in the Fireflies demo page claims that the Platform Preview is “Internet Explorer 7” while the status bar clearly indicates that it’s an IE10 Platform Preview build running in IE10 document mode:

If you look at the source of the demo site, you’ll notice that FeatureDetection.js includes the following code (typos and all):

The code isn’t looking for the Trident/6.0 token sent in the IE10 User-Agent string and hence doesn’t realize that this PPB has loaded the site with Browser Mode: Internet Explorer 10 Compatibility View. The page itself is running in IE10 Document Mode because it includes the following META tag:

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

Because the page is properly running in IE10 Document Mode, the markup (including the CANVAS element) continues to work correctly, but the “What browser are you using” notice at the bottom left is misleading.

You might be wondering why the video indicates that the page was loaded in Browser Mode: IE10 Compatibility View. The answer is simple-- when the video was recorded, the new Fireflies demo hadn't yet been published. We were using the PPB to load a mirror copy of the demo from an internal staging server on our Intranet. By default, Internet Explorer runs Intranet pages in Compatibility View.

Now, when you visit the IETestDrive site, you should see a proper browser identifier because the browser will be in IE10 Browser Mode:

-Eric

Update now available for improved font-smoothing

EricLaw [MSFT] — Wed, 29 Jun 2011 03:19:00 GMT

Today’s batch of Windows Updates included a “Recommended” update to improve the rendering of certain fonts at small sizes (8-10pt). The updated versions of Arial, Verdana, and Tahoma fonts include new hinting logic that renders more clearly using sub-pixel-positioned ClearType text rendered using the DirectWrite APIs used by Internet Explorer 9's hardware-accelerated text rendering.

I put together a simple test page for these changes here: http://www.debugtheweb.com/test/ClearType/. Using the comparison widget, you can see that Arial's c gets a little wider, dots on i and j get a little bolder, 10pt Verdana's 5 changes a bit, 10pt Arial's 0 gets a bit skinnier, and many of 9pt Verdana's characters gain a bit of weight.

-Eric

PS: The Firefox guys wrote a bit more about this as well.

Understanding Once-Per-Session Cache Validation

EricLaw [MSFT] — Wed, 15 Jun 2011 01:04:00 GMT

Last year, I wrote about the IE9 improvements in heuristic expiration, which apply when a server fails to specify how long a cached resource should be treated as fresh. Heuristic Expiration works by calculating an implicit freshness lifetime from the Last-Modified timestamp on the cached resource and the timestamp at which the resource was downloaded from the server.

However, the Heuristic Expiration calculation only applies when the user’s Check for newer versions of stored pages option (a.k.a. "SyncMode") inside Tools > Internet Options > Browsing History Settings is set to Automatically.

As mentioned, the heuristic expiration feature relies upon the server providing a Last-Modified timestamp on the response. If the server fails to provide such a timestamp, then Internet Explorer will fall back to its Once-Per-Session syncmode for that resource. A user may elect to use Once-Per-Session syncmode (for all resources) in lieu of Heuristic Expiration by selecting the Every time I start Internet Explorer radio button.

WinINET keeps track of when the current process has started in a variable called SessionStartTime. Every entry in the WinINET cache has a LastSyncTime. If the cache syncmode is Once-Per-Session, when WinINET is deciding whether or not to reuse a resource of unknown freshness, it compares the resource’s LastSyncTime to the process’ SessionStartTime. If the LastSyncTime is earlier than the SessionStartTime, WinINET will not immediately reuse the cached version and will instead make a network request to the server to check for freshness, potentially downloading an updated version of the resource in the process.

Once-Per-Session syncmode has a few non-obvious subtleties.

To establish an upper-bound on reuse, WinINET will also perform revalidation if the current time is more than 12 hours after the LastSyncTime.
In any version of IE, if a page’s JavaScript executes the ClearAuthenticationCache command, that invokes the INTERNET_OPTION_END_BROWSER_SESSION operation in WinINET. Internally, the EndBrowserSession option (among many other operations) invokes the INTERNET_OPTION_RESET_URLCACHE_SESSION operation, which sets the current process’ SessionStartTime to the current time. So, if any page invokes this API, any “Once per session” resources will be revalidated before being reused by the current process.
If INTERNET_FLAG_HYPERLINK is present on the request, and a cached response doesn’t have a Last-Modified value set, then WinINET will always revalidate the cached resource before reuse, ignoring the Once-Per-Session rule. IE9 uses FLAG_HYPERLINK (via BINDF_HYPERLINK) when performing most document (e.g. top-level or frame) downloads.
In Internet Explorer 8, simply opening a new tab (which creates a LCIE Tab process) would reset the SessionStartTime for all other tabs in the current Browser Session. This behavior hurt performance, and was corrected in IE9. In IE9, every new tab process in a Browser Session will inherit the original SessionStartTime for the browser session, eliminating this performance penalty.

So, what does this gobbledygook all mean to you, the web developer? Avoid the confusion and unpredictability of cache heuristics and specify an explicit expiration time!

Thanks,

Eric

First IE9 Update Now Available

EricLaw [MSFT] — Tue, 14 Jun 2011 21:25:00 GMT

As announced over on the IEBlog, the first update for IE9 is now available. When this update is installed, the IE Help > About screen will indicate that the IE version is 9.0.1.

Please note that this is a display only change and it is not reflected in the User-Agent String, Conditional Comments, or the version information returned by the getComponentVersion API.

Beyond the usual batch of security and reliability fixes, this update contains two fixes for the IE9 download manager. First, it resolves an issue where the IE Download Manager would sometimes get “stuck” at 99% if the page that spawned a download was closed before the download completed. Second, it resolves an issue where under some circumstances, the “This type of file could harm your computer” notice was still shown even when the SmartScreen Application Reputation feature is enabled. There are a handful of other functionality fixes in this update as well, described in the very-slow-to-load KB article:

A webpage stops responding after you close a modal dialog box that is started by a VB6 ActiveX control in Internet Explorer 9
Memory leak when the window.createPopup method and the document.createStyleSheet method are used in Internet Explorer 7 or in Internet Explorer 8
Tasks may not be displayed in the Jump List of a pinned Internet Explorer 9 icon in Windows 7 or in Windows Server 2008 R2
You cannot edit a cell in a DHMTL grid after you delete the cell's contents in Windows Internet Explorer 8 on a computer that is running Windows Vista or Windows Server 2008

-Eric

Download Resumption in Internet Explorer

EricLaw [MSFT] — Fri, 03 Jun 2011 17:55:00 GMT

While most file downloads are quickly and successfully completed, some large downloads take a long time to complete, and may be interrupted in the middle by either the user choosing to “Pause” or due to networking glitches (e.g. WiFi connection dropped).

One of the significant enhancements in the IE9 Download Manager is enhanced support^[1]for download resumption. Download resumption enables users to resume the transfer of a file at the point of interruption instead of re-downloading the entire file over again. In order for Internet Explorer to consider a download to be resumable, several conditions must be met:

The URL must be HTTP or HTTPS
The server must not have sent the response header Accept-Ranges: none
The server must send a strong ETAG header on the response
The server must respect the Range header on the subsequent download request

Download resumption works by sending a HTTP Request specifying what version of the resource the client currently has (identified by the ETAG) and the range of the file that the client would like the server to send. For instance, here’s the request that is sent if the user clicks the Resume button in the download manager:

GET /BigFile.exe HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: 127.0.0.1
Range: bytes=700000-
If-Range: "StrongETAG"
Connection: Keep-Alive

If the server is capable of resuming the download, and the version identified by the client (using the If-Range header) is still available, the server will send a HTTP/206 response with a Content-Range header indicating the portion of the file that the server is sending. If the server is unable or unwilling to deliver the range requested by the client, it may send a HTTP/200 response and start the download over from the beginning.

In some cases, we’ve heard from users who do not understand why they cannot resume certain incomplete downloads.

Some servers simply don’t allow download resumption, either forbidding it explicitly using Accept-Ranges: none or implicitly by never returning a HTTP/206 response. The advantage to explicitly sending Accept-Ranges: none is that the Download Manager’s Pause button is disabled, to spare the user from trying to pause a download only to find out later that they must restart it from the beginning.

In many cases, the problem is that the server failed to specify an ETAG that allows the client to ensure that it is resuming the correct file^[2][3]. In a few cases, we’ve seen servers that send “weak” ETAGs; strong ETAGS must begin and end with quotation marks. If the response lacks a strong ETAG, the Pause button is disabled.

Even when a server otherwise supports resumption, in some cases, it will fail because the server requires some state information to allow the request (e.g. a Session cookie or HTTP Authentication) which is no longer available, because, for instance, the user closed and reopened the browser before attempting to resume.

-Eric

^[1]IE8 and below could resume downloads under ideal circumstances, but in practice these circumstances were very rarely achieved.
^[2]For instance, Download.com isn’t currently sending ETAGs on their file downloads.
^[3] Sites that send Vary headers on their responses should also always send an ETAG on such responses to allow the browser to conditionally revalidate such responses.

Consent and Browser Refreshes

EricLaw [MSFT] — Wed, 25 May 2011 02:35:00 GMT

Modern browser APIs like the GeoLocation API are designed to have an asynchronous consent experience, whereby the API simply will not undertake a privileged action until the user consents. Unfortunately, many browser features like popup windows and ActiveX controls were designed before privilege limitations were introduced, and many websites are designed with the expectation that the API will succeed immediately and synchronously.

When features like the Popup Blocker, Per-Site ActiveX, ActiveX Filtering, or Tracking Protection block an action requiring consent, Internet Explorer will refresh the web page if the user grants permission (e.g. by clicking an Unblock or Allow button). The problem is that if the browser prevents anything (e.g. an ActiveX control or popup) from loading at the expected time, JavaScript that might have depended upon its presence may fail (perhaps spectacularly) and not automatically recover when the user unblocks the content and that content eventually becomes available.

By refreshing the page after unblocking the content, Internet Explorer can limit the compatibility impact of the consent experience by ensuring that scripts and controls are loaded at their expected time when the page reloads. Unfortunately, this refresh can be disruptive, for instance, if you’ve entered data on the page, it may be lost when the browser refreshes.

Web Applications can be designed to avoid consent experiences and ensure that if APIs are blocked, a script error does not result.

For instance, the Outlook Web Access (OWA) team responds to popup blocking in a clever way. By default, popups are only permitted after a user-initiated action (click, Enter keypress, etc). OWA is designed such that most popups are the direct result of a user-initiated click and avoid the popup blocker automatically. However, some notifications may show at unexpected times and result in a block:

If OWA detects a popup was blocked (e.g. window.open returned null) then it shows the following HTML prompt.

When the user clicks on the Yes button, this click is treated as a user-initiated action, and the popup window will be permitted. If the second attempt to open the popup fails, the web application knows that the user is in a non-standard configuration (e.g. “Block all popups”) and notifies the user:

If the user clicks the Allow button rather than interacting with the OWA prompt, Internet Explorer will attempt to refresh. OWA has an OnBeforeUnload handler that warns the user that the Refresh will lose content:

If the user chooses to Stay on this page, then the page refresh is skipped, and the mail message is preserved.

In IE9, we’ve made an improvement so that the “Allow page to use popups” flag remains set on the current markup despite the lack of refresh, so the next time a popup is invoked, permission is granted based on the user’s consent. [Test Page]

As a best practice, web applications should expect that privileged APIs with consent experiences may not immediately succeed.

-Eric

Enhanced Mitigation Experience Toolkit Update

EricLaw [MSFT] — Tue, 24 May 2011 19:03:00 GMT

Microsoft’s Security Research and Defense team has released an updated version of their Enhanced Mitigation Experience Toolkit, a tool that allows the application of enhanced security mitigations around the application of your choice.

While Internet Explorer 9 already natively includes many of the protections that EMET provides (including DEP/NX and SEHOP), the tool includes several mitigations that are not otherwise available, including the ability to force all DLLs to load with randomized base addresses (aka ForceASLR). These mitigations can help prevent exploitation of certain types of memory-related vulnerabilities-- for instance, the SRD team blogs about a case where EMET blocked an exploit of a PDF Reader application by randomizing the base address of modules it loads.

EMET has moved out of its experimental incubation phase and is now an officially supported Microsoft product.

-Eric

Socially-Engineered XSS Attacks

EricLaw [MSFT] — Thu, 19 May 2011 17:40:00 GMT

When the IE team talks about Cross-Site-Scripting (XSS) attacks, we’ve usually grouped them into three categories

Type 0: DOM-based XSS
Type 1: “Reflected” XSS
Type 2: Persistent/Stored XSS

DOM-APIs like toStaticHTML enable pages to protect themselves against Type 0 attacks. The Internet Explorer XSS Filter can block Type 1 attacks by detecting reflected script and neutering it. Servers can protect themselves against Type 2 attacks using the Anti-XSS library to sanitize stored data.

It turns out, however, that there’s a fourth type of XSS attack: Socially-engineered XSS. In a socially-engineered XSS attack, the user is tricked into running an attacker’s JavaScript code in the context of the victim site. Even if a site follows best-practices to block XSS Types 0, 1 and 2, they may still be vulnerable to Socially Engineered XSS attacks.

Such attacks work in the same way as most socially-engineered attacks, by attacking the weakest link in browser security—the user’s trust. The attacks request that the user perform a series of operations (often using keyboard key combinations) that result in a JavaScript URL being entered in the address bar and invoked. JavaScript URIs entered in this way execute in the context of the currently loaded page. Users are tricked into following these instructions with the promise of some reward (e.g. free “points” for games, “secret” information about other users, etc).

Here’s a screenshot of an attack that I encountered yesterday:

Now, I’ve seen far slicker versions that mask themselves far more cleverly, such that the script isn’t ever seen. In the manner of an old game cheat, the unknowing user presses CTRL+C, CTRL+L, CTRL+V, ENTER, and the bad guy’s code runs.

These attacks often target popular social networks, and their first action upon running is to spread to all of the user’s contacts, leading to an extremely rapid infection across the social graph. Thousands of users can fall for an attack like this in a few hours. After arranging to spread to the user’s contacts, these attacks typically engage in spamming malware-distributing links or other activities that generate revenue for the bad guys. Because the script runs in the security context of the victim page, any information on the current site may be available for perusal by the attacker.

In Internet Explorer 9, we’ve added a simple protection that significantly raises the bar against this type of attack. Specifically, IE9 will remove the “JavaScript:” prefix^[1]from any string that is pasted into the address bar. So, in order for a user to fall victim to a self-inflicted attack of this nature, they have to be persuaded to copy/paste the attack code in the address bar, then go to the beginning of the URL, type “javascript:” and hit enter. This additional step adds complexity (and suspicion), and our early data that indicates that IE9 users are much less likely to fall victim to such attacks.

Web-elites who would recognize this attack immediately (e.g. many readers of this blog’s small readership) might think this new protection cumbersome, since they can no longer trivially paste things like “javascript:alert(document.cookie);” into the address bar to see the current page’s cookies. However, IE will still allow pasting of the code itself, so you need only type the JavaScript protocol prefix. For script operations you undertake frequently, you can store the code in a simple Bookmarklet and simply invoke that rather than trying to paste in the address bar. Internet Explorer 9 includes several improvements for bookmarklets. In IE9, a bookmarklet may now contain up to 5kb of JavaScript (previously, the limit was 2083 characters), and bookmarklets may again be dragged from a webpage into the Favorites bar, triggering the following prompt:

-Eric Lawrence

^[1] Internet Explorer will actually strip out any script-prefix, including misspelled strings that might otherwise be autocorrected into a script prefix. Also, if there's existing content in the address bar (e.g. a j) if adding pasted content (e.g. avascript) will create a script prefix, it will still be removed.

Detecting Captive Network Portals

EricLaw [MSFT] — Wed, 18 May 2011 13:50:00 GMT

Over on SuperUser, there’s a great explanation of how Windows determines whether a newly-connected network has a proper Internet connection, or whether the user should open a browser to login or click through a Terms of Use agreement. The general idea is that Windows will attempt to download a webpage from a well-known URL, and if there were any errors or unexpected results, the user sees the prompt.

Applications which want to make use of this information can use the Network List Manager API. There's a get_IsConnectedToInternet method on the INetwork interface and the captive portal flag can be found by looking at the VT_UINTs named NA_InternetConnectivityV4 and NA_InternetConnectivityV6 in the INetwork's property bag. If the flag NLM_INTERNET_CONNECTIVITY_WEBHIJACK is set, then a captive portal was detected.

-Eric

URL Fragments and Redirects

EricLaw [MSFT] — Mon, 16 May 2011 23:20:00 GMT

I’ve worked on the Internet Explorer team for six+ years, and on web sites for a decade longer, so I’m understandably excited when I come across a browser behavior I can’t explain. Last week, I encountered such a mystery, and it took me quite a while to figure out what was going on.

Background

Facebook tends to use URL Fragments in their URLs. For instance, a car dealer’s website includes a link to their Facebook page thusly:

http://www.facebook.com/#!/MBofWhitePlains?sk=app_192229990808929

The Fragment component of the URL is the end of the URL from the hash symbol (#) onward. URL Fragments are never sent to the server in the HTTP request— only JavaScript running in the page can see them. So, when your browser loads the URL above, the server sees only “http://www.facebook.com” in the request, and it’s the responsibility of JavaScript in the returned page to examine the URL to find the extra information in the Fragment.

Clicking on the link will go to the specified URL:

…and then script on the page will redirect you to a final page which contains the “MBofWhitePlains” identifier in the URL path, clearing out the URL Fragment.

Now, you may have heard that Facebook now offers an opt-in choice to always use HTTPS when loading Facebook:

If you set this option, Facebook will immediately return a HTTP/302 redirect for a HTTPS page if your browser ever requests a page using HTTP.

That’s a problem for this scenario: because the URL Fragment is never sent to the server, the server sends your browser a redirect to https://www.facebook.com, with no URL Fragment specified. Hence, when the redirected page is loaded, the URL Fragment is blank, and you’re left on the Facebook homepage.

Now, this made perfect sense to me—a simple limitation of the way Facebook is using URLs.

Except for one thing…

While Safari and Internet Explorer both behave as expected, Firefox, Chrome, and Opera were somehow landing on the HTTPS version of the car dealership’s Facebook page—not the homepage. This was a truly surprising outcome, and I spent a ton of time ensuring that the different behavior wasn’t related to Facebook performing User-Agent sniffing and returning different responses, or anything of the sort. It turns out that the code was the same, but the browser behavior was very different.

Peeking behind the curtain

After much debugging, I realized that Firefox, Chrome, and Opera will re-attach a URL Fragment after a HTTP/3xx redirection has taken place, even though that fragment was not present in the URL specified by the Location header on the redirection response. So

In Chrome/Opera/Firefox

Loading http://foo/#SomeInfo –> HTTP/302 to Location: http://bar => final URL of http://bar/#SomeInfo

In Internet Explorer and Safari

Loading http://foo/#SomeInfo –> HTTP/302 to Location: http://bar => final URL of http://bar/

Here’s a simple test page: https://www.fiddler2.com/test/redir/fragment/ demonstrating this behavior:

Interestingly, Chrome, Firefox, and Opera reattach the fragment information even in a cross-domain redirect, and even when redirect from HTTPS to HTTP.

I wasn’t able to find anything in the HTML5 specification calling for this behavior:

The HTTP specification (RFC2616 and the active HTTPBIS revision) doesn’t specify proper behavior either, noting only that the behavior when the Location header itself contains a URL Fragment is not defined:

Note: This specification does not define precedence rules for the case where the original URI, as navigated to by the user agent, and the Location header field value both contain fragment identifiers. Thus be aware that including fragment identifiers might inconvenience anyone relying on the semantics of the original URI's fragment identifier.

…although almost all browsers appear to respect a URL Fragment specified on the redirect response. Specifically, if both the original URI and the redirect Location specify a fragment-- Internet Explorer, Chrome, Firefox, and Safari will use the Fragment component from the Location header. Opera 11.01 will instead keep the Fragment component from the original URL; they only use the Fragment component from the Location header if the original URL didn't contain a fragment at all. Opera 11.11 changed that behavior to match Chrome and Firefox.

Interesting stuff.

-Eric

Controlling Java in Internet Explorer

EricLaw [MSFT] — Sun, 15 May 2011 19:12:00 GMT

Recently, there’s been some interest in how to control the use of Java within Internet Explorer. Java is a unique form of extensibility because it can be invoked in two ways:

Using an APPLET element
Using an OBJECT element with a CLSID of a JVM

These two invocation methods are subject to different security controls, which I’ll describe in today’s post.

Controlling Applet Tags

When Internet Explorer encounters an APPLET tag, it checks the URLACTION_JAVA_PERMISSIONS value to determine whether the APPLET should be loaded. If the value is URL_POLICY_JAVA_PROHIBIT, then the APPLET tag is prevented from loading the JVM. In earlier versions of Internet Explorer, when a Microsoft JVM was available, this URLAction was exposed on the Tools > Internet Options > Security > Custom… dialog, but it has since been removed.

You can use the Group Policy Editor to control the URLAction under the node \Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page\ZoneID:

Alternatively, you can make a small registry tweak to add the JVM Options entry back to the Internet Control Panel:

The registry script takes advantage of the fact that the Internet Control Panel UI is extensible via the registry; it simply creates a new item that adjusts the values of the URLACTION_JAVA_PERMISSIONS URLAction.

If you adjust the Internet Zone settings from “High Security” to Disable (URL_POLICY_JAVA_PROHIBIT) any site attempting to use an APPLET tag will find that the applet does not load and a notification is shown:

Controlling Object Tags

Unfortunately, when a site uses an OBJECT tag to load Java, an entirely different codepath is executed. In the OBJECT tag case, the JAVA_PERMISSIONS URLAction isn’t consulted, because as far as Internet Explorer is concerned, this might be any type of OBJECT. Instead, the traditional ActiveX-controlling features are consulted (e.g. ActiveX Filtering, Per-Site ActiveX, Manage Add-ons, etc). You can use IE’s Tools > Manage Add-ons feature to examine or adjust the state of the Java Plug-in object:

Note: I’m told that the Java Plug-In SSV Helper Browser Helper object should not be disabled, as it ensures that websites may not attempt to load older (insecure) versions of the JVM you may have installed. However, you’ll notice that you pay a performance penalty on tab startup to load this BHO—this is one of the many reasons I don’t install Java on my PCs.

If you select the Java Plug-in, you can click the Disable button to prevent Java from being loaded by an OBJECT tag. Alternatively, if you click the More Information link, you can clear the * from the list of sites on which the Java Plug-in may run:

If you subsequently visit a site that attempts to invoke Java as an OBJECT tag, you will see a notification bar prompting you for permission to run Java on the current site.

So, if you want to permit Java to run only in the Intranet and Trusted Sites zones:

Adjust the URLAction for the Internet Zone to Disable
Remove the * from the Per-Site list of the ActiveX Control

Step #1 will ensure that only Intranet Zone and Trusted Zone sites may load Java for APPLET Tags. Step #2 will ensure that the Java Plug-in will not load as an OBJECT on Internet Zone sites; a notification will be shown instead. Because Intranet and Trusted Sites ignore the Per-Site ActiveX list, you won’t see any additional warnings on those sites.

-Eric Lawrence

Stylesheet Limits in Internet Explorer

EricLaw [MSFT] — Sat, 14 May 2011 21:14:00 GMT

KB 262161 outlines the maximum number of stylesheets and rules supported by Internet Explorer 6 to 9.

A sheet may contain up to 4095 rules
A sheet may @import up to 31 sheets
@import nesting supports up to 4 levels deep

Some folks have wondered about the math that underlies these numbers. The root of the limitations is that Internet Explorer uses a 32bit integer to identify, sort, and apply the cascading rules. The integer’s 32bits are split into five fields: four sheetIDs of 5 bits each, and one 12bit ruleID. The 5 bit sheetIDs results in the 31 @import limit, and the 12 bit ruleID results in the 4095 rules-per-sheet limitation. While these limits are entirely sufficient for most sites, there are some sites (particularly when using frameworks and controls) that can encounter the limits, requiring workarounds.

There’s a simple test page for the limits here.

-Eric

Update: IE10 Platform Preview #2 significantly raises the limits described above. In IE10 (any browser/document mode):

A sheet may contain up to 65534 rules
A document may use up to 4095 stylesheets
@import nesting is limited to 4095 levels (due to the 4095 stylesheet limit)

Avoid “Do not save encrypted pages to disk”

EricLaw [MSFT] — Sat, 07 May 2011 02:05:00 GMT

Internet Explorer has an Advanced option named Do not save encrypted pages to disk. By default, this option is unchecked (except for Windows Server systems) and I recommend you leave it that way.

In IE9, this option does exactly what it says it does—resources received from HTTPS URLs are not placed in the Temporary Internet Files Cache and temporary files are not created for these resources. This option is universal for HTTPS responses; their headers (e.g. Pragma, Cache-Control) are not consulted.

While that might sound appealing to some readers, it’s important to realize that this will break any scenario where a file is needed.

There are two key scenarios when a file is required:

File downloads.
When an add-on or other code sets the flag INTERNET_FLAG_NEED_FILE on a request.

If a file download is attempted from HTTPS when this option is set, the secure download will fail:

Similarly, some plugins like Flash will set the NEED_FILE flag when issuing a HTTPS request, and those requests will fail in this configuration. For instance, when Pandora attempts to login, their XML request fails:

In IE8 and lower, the behavior of the checkbox was much more complicated, modified by a number of cumulative updates over the years. At a high-level, if a Pragma: no-cache was present on the HTTPS response, then no cache or temporary file would be created. If other no-cache headers were present, then the cache or temporary file might be created based on a very complicated set of logic, involving whether the response was compressed, and depending on the ordering of the no-cache and no-store tokens in the response’s Cache-Control header.

If you do not want HTTPS-delivered content to be stored in your cache, then you are better off setting the Empty temporary internet files folder when browser is closed option instead. Downloads and Flash applications will work properly, and IE will clear the cache completely when the browser is closed. If you're worried about local attacks with full access to your hard drive, enable BitLocker Drive Encryption, which will protect not only your cache files, but also your swap file.

-Eric