Security tweaks in IE7

IEBlog

Windows Internet Explorer Engineering Team Blog

Security tweaks in IE7

  • Comments 67

As we’ve described previously, we’ve made some major architectural improvements to improve browsing security in Internet Explorer 7, including Protected Mode, Phishing Filter, Enhanced Validation SSL, and other features in support of our overall security strategy.

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)
Host: www.example.com
Authorization: Basic RXJpYzpUb3BTZWNyZXQ=

You can use Fiddler’s Tools > Text Encode/Decode tool to decode the base64 string, into the username:password string: 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:

Auth Warning

In addition to the warning text, there are two ways to block the use of Basic Authentication over an unencrypted connection:

  1. Create the following registry DWORD and set it to a non-zero value: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\DisableBasicOverClearChannel. This prevents Internet Explorer and other WinINET applications from attempting to use Basic unless the channel is secured (using SSL/TLS).
     
  2. 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:

          <html>
          <body>
          <script src='http://good.example.com/useful.js'></script>
          This page is running on good.example.com. It has very valuable content that lots of folks want to see.
          <script src='http://evil.example.com/annoy.js'></script>
          </body>
          </html> 

Now, say that http://evil.example.com/annoy.js contains something like:

          for (var x=0; x<100000; x++){
                   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

  • Loading...