Security tweaks in IE7

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)
Authorization: Basic

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



          <script src=''></script>

          This page is
running on It has very valuable content that lots of folks
want to see.

          <script src=''></script>



Now, say that 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 in the restricted sites zone to block annoy.js from running on’s pages (since script in the HTML runs in that page context).
This is unfortunate, because 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 in your restricted sites zone. Thereafter, no
script from 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

Comments (67)
  1. Fredrik W says:

    There isnt any form of autoblocking "evil" javascripts though, so the user will still see them in the first place and get mad.

  2. Dave says:

    First, bravo for implementing the change to use the domain of the script source. I bugged this in XP SP2 beta but encountered the "By design, Wookies don’t live on Endor" defense.

    Can you elaborate how this will apply? If a page on includes a script from, will it allow that script to run even though the base page is untrusted and none of its scripts are allowed? Or do those scripts get the lesser privileges of the two zones?

  3. Al Billings [MSFT] says:

    I’m not familiar with the "Wookies don’t live on Endor" defense though it makes me think of the Southpark…

  4. Dave says:

    Yes, South Park. To paraphrase Johnnie Cochran, "Why would IE let a script, a script from *another domain*, run just because it’s on a page with a bunch of trusted HTML? That does not make sense! If the domain is untrusted, the script must be busted."

  5. PatriotB says:

    Good stuff.  Little stuff often does add up, so keep blogging about changes such as these.

  6. cooperpx says:

    Please don’t take offense, but how did IE7 Beta 1 and 2 get released with malfunctioning digest authentication (if you were concerned about basic authentication)?

    More over, nobody at Microsoft will awknowledge my past reports that digest authentication with IE7 (Beta 1 and 2) is malfunctioning.

  7. cooperpx says:

    Eric Lawrence Says " 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."

    How does an application that uses WinHTTP enable basic authentication, without modifying the registry? (and potentially causing global issues)

  8. Eric says:

    Cooperpx: The bugs in Digest support are known and have been acknowledged on this blog and in the newsgroups.  We’re working on these for a future release.

    Sorry that this wasn’t more public.

    Dave: No, a Restricted site will not run scripts, even from a non-restricted site.  We’ve simply added a check to ensure that if a non-Restricted site tries to pull in a script from a restricted site, that script won’t run.

    Thanks for the feedback.

  9. EricLaw [MSFT] says:

    CooperPX: I’m not an expert on WinHTTP, but as far as I know, WinHTTP doesn’t have any mechanism to pop authentication UI.  

    Hence, handling of authentication would be performed by the client application and the client would determine whether or not its criteria for responding to a given Basic challenge (e.g. must be SSL) have been met before it adds credentials.

  10. Um… what *other* forms of authentication will be supported besides Basic?  NTLM, I assume… but what about CHAP or some other non-Windows-only form of password encryption?

  11. In particular, is RFC 2617 Digest Authentication supported?


    Apache supports NTLM security but only if the mod_ntlm plugin is installed.

    IIS supports Digest authentication (not on by default) but only if the Active Directory passwords are stored in "reversible encryption" (not the default)

  12. Never mind, I think I found my answer:

    I assume everything there stays the same for IE 7.

  13. EricLaw [MSFT] says:

    By default, IE/WinINET supports Kerberos, NTLM, Digest, and Basic authentication.  

    Through various means, IE also supports a variety of pluggable authentication providers, including Passport and the upcoming Infocard.

    Please see for some more details on authentication.

  14. cooperpx says:

    Eric, thank you ever so much! I had a huge sigh of relief as I no longer have to think about a new authentication mechanism for unencrypted channels. Digest is great for preventing replay attacks.

    It’s also good to know that your registry setting doesn’t affect WinHTTP. 🙂

    I can’t wait for the next Beta!

  15. I was testing Digest Authentication on my Windows 2000 server.  IE 6 connects fine.  Firefox has a problem where only the first request succeeds.  It’s not clear to me at this point whether this is a bug in Firefox (which seems likely) or a difference in interpretation of RFC 2617.

  16. cooperpx says:

    Maurits: IE has traditionally not sent the content after the "?" in the url with the Digest Authentication Header. Firefox, along with a number of other browsers, will.

    The "difference of interpretation of RFC 2617" can only be corrected on the web server, as it has to "not care" that the URL in the Authentication Header do not match the request (likely just the part after the "?").

    Firefox, prior to 1.0, has had a nasty history of getting Digest Authentication wrong, especially when it comes to nonce counting. Squid is also guilty of messing up nonce counting. However, they have a solid implementation now. I’d fire up a session of Ethereal and watch the Authenticate headers fly by.

  17. kL says:

    On my implementation of digest auth IE displays… DNS error! 😀

    Firefox, Opera and Safari can log in without problems.

  18. Yair says:

    great work fixing the script zones issue.

  19. Marc says:

    Hmm… If I put * and * and sites like that in the restricted sites zone, a lot of annoying stuff disappears. 😀

  20. Cipher says:

    The 0-bit cipher is documented in the knowledge base 🙂

  21. mocax says:

    an aside, why does IE7 try to reload a page if it takes too long to load?

    Was doing credit card payment when the payment processor warned me that I’ve repeated my transaction.

    Their site was experiencing a slight slowdown, but well within tolerance limits.

    Didn’t happen with IE6 and other browsers though.

    How do I disable the auto-refresh "feature"?

  22. duncan says:

    Thanks, been a bit of an eye opener.

  23. Alex Lein says:

    "IE7 on Windows Vista will also add the 256bit AES cipher to the list offered when negotiating a TLS connection."

    Will Windows XP SP2 not support 256bit ciphers?

  24. Here’s a dump of the headers

    Firefox breaks on the second authenticated request (third request overall)

    IE does not

    Server is an IIS 5 server – no query string in the request, no linked content from the page

  25. I’ve narrowed it down to a bug in Firefox.

    On the first authenticated request, Firefox correctly states qop="auth"

    On the second Firefox INCORRECTLY leaves out the quotes as qop=auth

    The RFC does explicity state that qop must take a quoted string.

    IIS and IE are correct here.

  26. I’ve uploaded a Bugzilla patch for Mozilla, just in case anyone’s following…

  27. prointech tech support says:


    there is achance to be invite for vista beta testing ?



  28. Yuhong Bao says:

    The warning should be:

    Warning: The server is requesting that the browser send your user name and password be sent in unencrypted plain text. A hacker could use a network sniffer to "sniff" for your user name and password, and when they do, they see your user name and password in plain text.

  29. FWIW, Digest authentication also sends the username in plain text (but not the password.)

  30. EricLaw [MSFT] says:

    @Alex: IE derives its SSL support from Windows components named SChannel and CryptoAPI.

    IE7 setup will not update those components.  If (and Microsoft has no announced plans here) these components are updated later (say in a service pack or whatnot) IE will take advantage of any additional ciphers added.

    @mocax: The issue with the 30-second timeout/refresh is known and will be fixed for a future beta release.

  31. asdf says:

    What I’ve always wished for is that instead of 4 (or 5 with that secret regkey) security zones, how about letting the user create an arbitrary amount and pick the order of lookup to have more fine-grained control over this.

  32. OOPS! I misread the RFC.

    Firefox is RIGHT.  IIS and IE are WRONG.  IE has one bug, and IIS has two.

    It helps to read the entire RFC.  The qop rules are different for

    server-to-client "WWW-Authenticate" headers than they are for client-to-server

    Authorization headers.

    For server-to-client WWW-Authenticate: headers, the rules are:

         qop-options       = "qop" "=" <"> 1#qop-value <">

         qop-value         = "auth" | "auth-int" | token

    That is to say, quotes are MANDATORY.

    On the other hand, for client-to-server Authorization: headers, the rules are:

         message-qop      = "qop" "=" qop-value

    That is to say, quotes are FORBIDDEN.

    There are thus three bugs.

    * one in IE, for generating the incorrect Authorization: header

    * one in IIS, for accepting the incorrect Authorization: header

    * another one in IIS, for refusing the correct Authorization: header.

  33. So we have the following facts:

    IE will start maligning Basic authentication.

    IE does not create correct Digest client authentication headers.

    IIS does not accept correct Digest client authentication headers.

    IIS *does* accept IE’s incorrect Digest client authentication headers.

    If I was paranoid, I would begin to think this is a conspiracy to push Microsoft products at the expense of standards.

  34. A quick test in IE 7 confirms that the IE bug persists.  qop="auth" is still being generated by IE 7 Beta 2.

  35. Will says:


    So we have the following facts:

    If IE were to change Digest, it would break thousands of sites all over the world and wouldn’t work with Microsoft’s own web server.  If they were to fix IIS, then the new IE would start working, except that all of the IE clients and IIS servers that hadn’t updated wouldn’t work.

    If I was paranoid, I would begin to think you’re a Firefox fanboy that is trying to infect Microsoft with the "implement standards even at the expense of making the product work" virus.  

  36. Xepol says:

    Of course, MS could release an RFC documenting some of their more advanced authentication techniques which would allow more browsers to support them, making them meaningful.

    SSL is nice, but too expensive and requires a third party.  We don’t always need to know that a third party warrents they are who they say they are just to ensure that a password isn’t sent plain text.

  37. Will…

    Well, at least you’re acknowledging the problem! 🙂

    Microsoft would have to fix it like this…

    1) Patch IIS to accept BOTH the standards-compliant qop=auth AS WELL AS the IE-common qop="auth"

    2) Wait

    3) Wait

    4) Wait

    5) Wait

    6) ONLY NOW patch IE to send the standards-compliant qop=auth instead of qop="auth"

  38. EricLaw [MSFT] says:

    Thanks for the feedback, Maurits.  I’ll talk to the IIS guys.  It’s interesting that Firefox is inconsistent in what they send; it’ll be interesting to see what they decide to do.

    @Xepol– Well, MS really only has one other authentication technique (NTLM) and it’s already implemented in Mozilla/Firefox, so it’s not clear what the request is here.  

  39. PatriotB says:

    "Alex: IE derives its SSL support from Windows components named SChannel and CryptoAPI. IE7 setup will not update those components."

    Of course, early versions of IE (IE3, maybe 4) *did* ship with and update those components.  Partially because (I believe) Windows 95 RTM didn’t have the CryptoAPI at all.

    There’s a lot of things that IE used to update, including the shell and common controls.  In many ways it’s unfortunate–both for third party developers (no new controls available with a new downlevel IE), and for IE itself (no updated crypto, etc).  But in the long run it’s probably for the best: having a well-defined set of dependencies, and a clear plan for what components can update or service other components, is necessary for increased quality.

  40. Anonymous says:

    You said ironically that Firefox is inconsistent. Of course you know that it is inconsistent because IE and IIS were not implementing the standards properly in the first place. So, first please learn to criticise your own products and then the competition.

    Also, I am not sure wether NTLM is documented anywhere. I think the Firefox has implemented it through reverse engineering. So, please document it.

  41. Mark Waterman says:

    I agree with Yuhong Bao. The warning message you describe should be totally meaningless to 95% of users. They don’t know what potential issues might arise from sending a username and password "in an insecure manner". You have to explicitly point out what might happen: hackers might easily get your password.

  42. The reason for Firefox’s inconsistency is documented in this bug:

    Basically, if it knows it’s talking to an IIS server, it will add the quotes.  However, my header trace shows that sometimes the server sniffing doesn’t work.

  43. For completeness, I want to point out that IE also incorrectly quotes the



    This is a minor bug — RFC-correct would be


    but it’s reasonable to expect servers to be able to interpret this correctly.

    IIS has the same SEVERE bug here though.

    IIS is OK with:

    Authorization: Digest … qop="auth", algorithm="MD5" …

    But IIS fails on

    Authorization: Digest … qop="auth", algorithm=MD5 …

    And also on

    Authorization: Digest … qop=auth, algorithm=MD5 …

    The last is a severe error, because that’s what RFC-compliant clients should send.

  44. Christian says:

    Did you know or realize how much users like to block ads?

    The mechanism of the hosts-file is well known to be used to block advertisement-hosts. Some of them changed to use IP-adresses because of this.

    Now the malicious sites security zone seems to be the ideal place to put banner-servers, layered ads, tribalfusion, doubleclickt, gooleads, etc. (Because IE will provide an easy way to block javascript from these pages)

    Soon many people will use this to block ads. Did you realize this? Did you want this?

    I love Firefox for its adblock-extension. It makes it soo easy to block all kinds of annoyances and ads and to completely kill the revenue. I love to do this, but Firefox has little market share.

    The technical aspects so far forced the ad-systems to strongly decouple ads from content.

    But I fear that now if IE provides unintentionaly an great mechanism to block ads (a bit like adblock which can block also javascript) that ad-services will start to set special javascript-variables and that the content pages will check these to see if ads were blocked and redirect the user or something like that 🙁

    Just some thoughts..

  45. EricLaw [MSFT] says:

    @Christian:  Our intent was to build a security feature; not an ad-blocker.

    I’ve talked about the risks to Firefox’s adblocker if IE introduced ad-blocking in the comments on previous posts. (For instance, once IE shipped a popup blocker, Firefox’s was less useful, since the ads just migrated to the page body).

    At the end of the day, someone hast to pay the hosting/operation fees for websites.  If everyone starts blocking advertising, then it’ll either get harder to block, or a new revenue model will develop.

  46. Nathan says:

    As a Developer, that often develops and runs tests on "localhost"… will there be a setting, whereby I can tell IE7, that I want ALL JavaScript, to run… today, tomorrow, always… with no warnings, no security toolbar, etc.

    NOTHING drives me more nuts, developing and testing in IE, than the "security toolbar" when developing on localhost.

    Did I mention that this is THE WORST ANOYANCE of Developing on IE?  If I didn’t, let me repeat it… it is a royal PIT_.

    Now, this has been brought up on this blog, and in almost every conversation I have with web developers… Can you please, please, please, separate the [Active Scripting] technologies in the various scripting options.

    Like everyone else out on the Internet, I want to DISABLE all versions of vbScript, and active X, and ENABLE JavaScript.  I don’t care if it is an advanced setting, that requires registry hacking but I get so anoyed, that my choices are: Turn it all off, to be safe from activeX and vbScript OR Turn it all on, just to get basic functionality.

    In IE7, the XMLHttpRequest object will finally be a native JavaScript Object, so, as of (mid-late 2006?) activeX will no longer be needed by anyone.  I would therefore like to shut it off completely.

    BTW: If I have overlooked the setting or option, please advise.

    Thanks a bunch.

  47. EricLaw [MSFT] says:

    Nathan: If you want to develop locally, you have two easy choices:

    1> Use your machine’s hostname.  It will run as the Intranet or Internet zone depending on whether or not you use the fully qualified domain name.

    2> Check the Tools | Internet Options | Advanced | Security: Allow active content to run from my computer option and restart IE.  Note that you shouldn’t browse the Internet in this configuration.

    As for disabling ActiveX, you can easily do that using the Security tab in Tools | Internet Options.  Simply select each zone, and set all of the ActiveX options to Disable.

    There’s no supported setting to disable VBScript only (and leave JScript active), but it’s very rare that the VBScript engine exposes a problem that’s not present in both engines.  

    It’s worth noting that there are a surprising number of sites that use VBScript for various purposes; I’ve even seen some google sites that use it for little tasks.

  48. Gabriel Iovino says:

    As Yuhong Bao and Mark Waterman pointed out, the warning message is FAR TOO CRYPTIC for the average user to understand what is happening. Please change that to something that *normal* users will understand.

  49. David.Wang says:

    Maurits – IIS6 and later accepts qop with and without quotes, so this should be a non-issue going forward.


  50. Great, thanks.

    So IE could in principle begin sending it without quotes as soon as IIS 5’s market share drops to an ignorable level.

    And if I want to roll out Digest Authentication I need to upgrade to IIS 6.

  51. David.Wang says:

    Maurits – You probably won’t see IE sending it without quotes until past 2010 or so.

    For example, look at IIS4/NT4 and how long it hangs around.

    And who by then will remember to yank it out in the then current IE code base? 😉


  52. Dave Bacher says:

    Registry settings to enable/disable basic authentication seems like a bad idea.

    It would most likely be better to move basic authentication to the security settings (per-zone), effectively creating a white list and black list for the basic authentication feature.

    Most (if not all) of what you say should be done this way.  For example, if I have to access a site that uses 56 bit encryption or 40 bit encryption, I should be able to create a "legacy (export) encryption zone" and assign those sites to that zone.  I should then be able to, through the GUI, assign those sites to the zone.

    If I were administering a large or important network, with thousands of people, I should be able to assign sites to this zone globally, versus having to change the setting on every individual machine (via a registry script) and having only on/off capability.

    Basic authentication is most often used in intranet situations where you are on an (incorrectly) assumed safe network, and connecting to non-IIS based web services that have used Basic authentication bceause their authors didn’t want to work out how to use a better authentication scheme.  In this scenario, it would be best to white list specific servers and black list anything not in the set.

  53. I would hope that basic authentication to would be exempt from the warning, for arbitrary values of :80 (though I don’t know whether that ever happens)

  54. I opened a support case re: IIS 5 rejecting standard Digest Authentication requests.

    The support engineer confirmed that they were able to reproduce what I was seeing; he confirmed that it was a bug in IIS 5; he recommended I upgrade to IIS 6, or require my visitors to use Internet Explorer; and he gave me the $99 back.

    I’m still concerned, due to:

    * IIS 5’s popularity


    * IE 7’s new "warning" message on Basic Authentication

    that the Digest Authentication SNAFU is tantamount to an unfair competitive advantage.

    I’m not saying it was intentionally designed to happen this way.  It’s very easy to misread the RFC.

    But now that it’s happened, I’m surprised how recalcitrant Microsoft is being to just fix the darn thing.

  55. EricLaw [MSFT] says:

    For what it’s worth, the WDigest component does have a registry override that can cause it (and IE7) to not quote the QOP parameter.

    This isn’t terribly useful, however, as servers appear to be robust in the face of receiving the unneeded quotes.  

  56. Riding Herd says:

    I’ve been using various beta builds of IE 7 for several months now, and I am really impressed with the…

  57. In Opera 9 Beta there are a lot of changes, as one expects from a major product release. Some of the changes (e.g. UI updates) are more apparent than other changes.  Some of the major, but less obvious, changes have been done …

Comments are closed.

Skip to main content