As we’ve described
previously, we’ve made some major architectural improvements to improve browsing
security in Internet Explorer 7, including
Enhanced Validation SSL, and other features in support of our overall
Our commitment to security goes both broad and deep-- While the major new features described above have received a lot of press, I’d like to mention just a few of my favorites
among the myriad tweaks we’ve made to existing IE features to improve security.
Enhancements for Basic Authentication
HTTP supports a variety of authentication methods; the simplest of them is called "Basic"
and it passes the username and password to the server using base64 encoding, which is trivial to reverse. For instance, here’s a Fiddler capture of a fictional login attempt:
GET / HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2)
You can use Fiddler’s Tools > Text Encode/Decode tool to decode the base64 string, into the
Eric:TopSecret. Since Basic authentication is trivially reversible, it should only
be used over an SSL connection to prevent a network eavesdropper from stealing credentials.
For IE7, we’ve left the Basic authentication mechanism available for compatibility reasons, but we’ve added text to the authentication prompt to warn the user anytime the server is
requesting Basic authentication over a clear (unencrypted) connection:
In addition to the warning text, there are two ways to block the use of Basic Authentication over
an unencrypted connection:
- Create the following registry DWORD and set it to a non-zero value: HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionInternet
SettingsDisableBasicOverClearChannel. This prevents Internet Explorer and other WinINET applications from attempting to use Basic unless the
channel is secured (using SSL/TLS).
- Any WinINET-based application can disable the use of Basic for its connections by setting the AUTH_FLAG_DISABLE_BASIC_CLEARCHANNEL flag (0x4) in the value supplied in the
call to InternetSetOption using INTERNET_OPTION_AUTH_FLAGS.
Lastly, we’ve made a change to IE7 to ensure that if the server offers multiple authentication methods, Basic is chosen only if no other authentication methods are
provided. In previous releases of IE, IE chose the first authentication method offered by the server.
Restricting Script using Zones
We’ve made a simple but powerful change to IE7’s security zone logic as it relates to scripting.
With Internet Explorer, scripts are mapped to a security zone using the URL context of the page from
which they are referenced, rather than using the origin of the script itself.
In some ways, this makes sense, because putting a SCRIPT tag with a SRC
parameter into your HTML is pretty much equivalent to putting the contents of
the .JS file directly into the HTML. Unfortunately, this approach limits the
user’s flexibility in controlling unwanted scripts.
For example, consider the following page at http://good.example.com:
This page is
running on good.example.com. It has very valuable content that lots of folks
want to see.
Now, say that
http://evil.example.com/annoy.js contains something like:
for (var x=0;
alert('Annoy annoy annoy'); // Make the user mad.
(Note: This example is a bit contrived because a "good" site isn’t going to intentionally pull in a
script from an evil site, but you can imagine that maybe the "good" site has a
Guestbook feature that doesn’t correctly sanitize input and block
cross-site scripting attacks.)
In prior versions of IE,
your options to avoid annoy.js were limited. You would need to put
good.example.com in the restricted sites zone to block annoy.js from running on
good.example.com’s pages (since script in the HTML runs in that page context).
This is unfortunate, because good.example.com may itself require other
scripts (e.g. useful.js) for normal use.
In IE7, we’ve taken a change to evaluate the source of a script in addition to evaluating its
page context. So, to allow useful.js to run while blocking annoy.js, you can
simply put evil.example.com in your restricted sites zone. Thereafter, no
script from evil.example.com will run, no matter where pages that may reference
it happen to be located.
Clarification about SSL ciphers
In addition to disabling SSLv2 by default, IE7 on Windows Vista will also disable legacy 40
and 56bit ciphers. IE7 on Windows Vista will also add the 256bit AES cipher to the list offered when negotiating a TLS connection.
While we’re on the topic of ciphers, I’d like to debunk one of the persistent urban legends that rears
its head every few months. "I hear there’s a 0-bit SSL Cipher. This means SSL
isn’t secure, right?" The answer is no, IE has never offered the so-called
"null-cipher" option to servers when making a HTTPS connection, and it will
reject any attempt to negotiate a null cipher.
As always, feedback is appreciated.
- Eric Lawrence