Security tweaks in IE7

Artikkeli
03/15/2006

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:

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 https://good.example.com:

<html>

<body>

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

</body>

</html>

Now, say that
https://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

Comments

Anonymous
March 15, 2006
There isnt any form of autoblocking "evil" javascripts though, so the user will still see them in the first place and get mad.
Anonymous
March 15, 2006
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 untrustedguy.com includes a script from niceguy.com, 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?
Anonymous
March 15, 2006
I'm not familiar with the "Wookies don't live on Endor" defense though it makes me think of the Southpark...
Anonymous
March 15, 2006
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."

http://en.wikipedia.org/wiki/Chewbacca_Defense
Anonymous
March 15, 2006
Good stuff. Little stuff often does add up, so keep blogging about changes such as these.
Anonymous
March 15, 2006
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.
Anonymous
March 15, 2006
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)
Anonymous
March 15, 2006
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.
Anonymous
March 15, 2006
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.
Anonymous
March 15, 2006
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?
Anonymous
March 15, 2006
In particular, is RFC 2617 Digest Authentication supported?

FWIW:
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)
Anonymous
March 15, 2006
Never mind, I think I found my answer:
http://support.microsoft.com/?id=258063

I assume everything there stays the same for IE 7.
Anonymous
March 15, 2006
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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wininet/wininet/handling_authentication.asp for some more details on authentication.
Anonymous
March 15, 2006
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!
Anonymous
March 15, 2006
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.
Anonymous
March 15, 2006
The comment has been removed
Anonymous
March 15, 2006
The comment has been removed
Anonymous
March 15, 2006
great work fixing the script zones issue.
Anonymous
March 15, 2006
Hmm... If I put *.doubleclick.net and *.tribalfusion.com and sites like that in the restricted sites zone, a lot of annoying stuff disappears. :-D
Anonymous
March 16, 2006
The 0-bit cipher is documented in the knowledge base :)
http://support.microsoft.com/kb/q261328/
Anonymous
March 16, 2006
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"?
Anonymous
March 16, 2006
Thanks, been a bit of an eye opener.
Anonymous
March 16, 2006
"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?
Anonymous
March 16, 2006
Here's a dump of the headers
http://www.geocities.com/mvaneerde/digest-test.txt

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
Anonymous
March 16, 2006
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.
Anonymous
March 16, 2006
I've uploaded a Bugzilla patch for Mozilla, just in case anyone's following...
https://bugzilla.mozilla.org/show_bug.cgi?id=330702
Anonymous
March 16, 2006
Hi,

there is achance to be invite for vista beta testing ?

thks

cesare

balenacesare@msn.com
Anonymous
March 16, 2006
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.
Anonymous
March 16, 2006
FWIW, Digest authentication also sends the username in plain text (but not the password.)
Anonymous
March 16, 2006
The comment has been removed
Anonymous
March 16, 2006
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.
Anonymous
March 16, 2006
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.
Anonymous
March 16, 2006
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.
Anonymous
March 16, 2006
A quick test in IE 7 confirms that the IE bug persists. qop="auth" is still being generated by IE 7 Beta 2.
Anonymous
March 16, 2006
The comment has been removed
Anonymous
March 16, 2006
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.
Anonymous
March 16, 2006
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"
Anonymous
March 16, 2006
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.
Anonymous
March 16, 2006
The comment has been removed
Anonymous
March 16, 2006
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.
Anonymous
March 16, 2006
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.
Anonymous
March 17, 2006
The reason for Firefox's inconsistency is documented in this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=141605

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.
Anonymous
March 17, 2006
For completeness, I want to point out that IE also incorrectly quotes the
algorithm="MD5"
parameter.

This is a minor bug -- RFC-correct would be
algorithm=MD5

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.
Anonymous
March 17, 2006
The comment has been removed
Anonymous
March 18, 2006
@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.
Anonymous
March 18, 2006
The comment has been removed
Anonymous
March 18, 2006
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.
Anonymous
March 19, 2006
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.
Anonymous
March 20, 2006
Maurits - IIS6 and later accepts qop with and without quotes, so this should be a non-issue going forward.

//David
Anonymous
March 20, 2006
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.
Anonymous
March 20, 2006
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? ;-)

//David
Anonymous
March 21, 2006
The comment has been removed
Anonymous
March 21, 2006
I would hope that basic authentication to http://127.0.0.1:80/ would be exempt from the warning, for arbitrary values of :80 (though I don't know whether that ever happens)
Anonymous
March 22, 2006
The comment has been removed
Anonymous
March 24, 2006
The comment has been removed
Anonymous
April 10, 2006
PingBack from http://adamcaudill.com/2006/04/10/ie7-of-time-standards/
Anonymous
May 05, 2006
I've been using various beta builds of IE 7 for several months now, and I am really impressed with the...
Anonymous
May 16, 2006
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 ...
Anonymous
April 30, 2008
PingBack from http://famousfunnymoviequoteblog.info/ieblog-security-tweaks-in-ie7/
Anonymous
June 12, 2008
PingBack from http://adolfo.thedigestonline.info/ie7tweaks.html
Anonymous
August 04, 2008
PingBack from http://agustin.freedownloadreport.info/vegandietill.html
Anonymous
January 31, 2009
PingBack from http://techsupersite.com/?p=140
Anonymous
May 29, 2009
PingBack from http://paidsurveyshub.info/story.php?title=ieblog-security-tweaks-in-ie7
Anonymous
May 31, 2009
PingBack from http://indoorgrillsrecipes.info/story.php?id=6006
Anonymous
June 11, 2009
PingBack from http://castironbakeware.info/story.php?title=ieblog-security-tweaks-in-ie7
Anonymous
June 12, 2009
PingBack from http://greenteafatburner.info/story.php?id=1961
Anonymous
June 16, 2009
PingBack from http://workfromhomecareer.info/story.php?id=29067

Jaa

Security tweaks in IE7

Comments

Lisäresursseja