Problem with Microsoft Security Bulletin MS04-004
Microsoft Security Bulletin MS04-004 provides a security update for Microsoft Internet Explorer and for a dependency component that is named WinInet. Security Update MS04-004 complies with section 3.2.2 of Request for Comments (RFC) 2616 and section 3.3 of RFC 1738. Both sections of these RFCs state that HTTP URLs must have only the following format:
http://host:port/path?querystring
Note host,
port, and
path are placeholders for the host name, the port number, and the location of the requested Web page on the server, respectively.
querystring is a placeholder for the parameters of the query string that must be passed to the server.
Security Bulletin MS04-004 includes an update that prevents a particular URL spoofing issue. Spoofing is the practice of tricking users into providing passwords and other information to allow unauthorized access into a system. In this scenario, users are tricked into thinking that they are browsing a particular Web site, when they are actually browsing a different Web site. Security update MS04-004 prevents the URL spoofing issue. However, after you apply Security Update MS04-004, some Web applications may break. The Web applications that are affected rely on the feature that passes credentials through the URL
Note Because Basic authentication credentials are passed across the network in clear text for every request that is sent from the Web client to the Web server, limit the use of Basic authentication. Only use Basic authentication when no other authentication methods are available. Also, use Basic authentication in conjunction with encryption such as TLS/SSL.
Microsoft concurs with the following warning that is provided in section 7 of RFC 2396:
It is clearly unwise to use a URL that contains a password which is intended to be secret. In particular, the use of a password within the 'userinfo' component of a URL is strongly disrecommended except in those rare cases where the 'password' parameter is intended to be public.
Microsoft recommends that you do not implement Basic authentication-based SSO solutions. However, this article contains several methods that you can use to work around the behavior that occurs after you apply Security Update MS04-004. When you use this method, previous systems that implement Basic authentication-based SSO solutions work just like they did before you installed Security Update MS04-004.
For additional information about Microsoft Security Bulletin MS04-004, visit the following Microsoft Web site:
SSO implementation
The following steps illustrate the implementation of an SSO solution by using Basic authentication.
Note This scenario works before you install Security Update MS04-004.
- A Web client requests PageOfInterest.asp from
ServerA.
Note PageOfInterest.asp, and ServerA are placeholders for the name of the requested page, and the name of the server where the requested page is stored, respectively. - ServerA responds to the Web client with a message the instructs the Web client to retrieve
PageOfInterest.asp from the following location:http://sbUsername:sbPassword@ServerB/SomePath/PageOfInterest.asp
This instruction is either sent in the Location header of an HTTP response with status code = 302, or it is sent as a “meta refresh” tag in the message body of an HTTP response with status code = 200.
Note sbUsername, sbPassword, ServerB, and SomePath are the placeholders for the username, the password, the name of the server where the requested page is stored, and location of the requested Web page on the server, respectively. Modify these values according to your environment. - The Web client requests
PageOfInterest.asp from
ServerB, and then provides credentials when challenged.
When Internet Explorer canonicalized a URL before you installed Security Update MS04-004, WinInet saved any credentials that you encountered between the protocol and host sections of the URL for later use in the communication between the Web client and the Web server. WinInet is the component that Internet Explorer uses to communicate over TCP/IP. If a subsequent request to the same Basic authentication realm returned a WWW-Authenticate: Basic response header, WinInet used a correctly formatted Authorization: Basic request header to issue another request to the Web server that includes the credentials that were saved during canonicalization. When the credentials are saved, the Web client can authenticate to the Web server, and the user is not prompted for credentials.
Sample sequence
The following is a sample of the HTTP data that is exchanged between an Internet Explorer client and a server computer that is running Microsoft Internet Information Services (IIS) in a typical Basic authentication sequence.
Note This sample was collected by using the WFetch utility. The \r\n characters represent the hexadecimal characters 0D 0A, or the ASCII character CRLF.
For additional information about the WFetch utility, click the following article number to view the article in the Microsoft Knowledge Base:
284285 How to use Wfetch.exe to troubleshoot HTTP connections
- The browser issues an anonymous request to the Web server.
GET /SomePath/PageOfInterest.aspx HTTP/1.1\r\n
Host: ServerB\r\n
Accept: */*\r\n
\r\n
- The Web server replies to the Web client that access is denied, and that the requested resource requires Basic authentication credentials.
HTTP/1.1 401 Access Denied\r\n
Content-Length: 4431\r\n
Content-Type: text/html\r\n
Server: Microsoft-IIS/6.0\r\n
WWW-Authenticate: Basic realm="ServerB"\r\n
X-Powered-By: ASP.NET\r\n
Date: Mon, 16 Feb 2004 00:38:11 GMT\r\n
\r\n
[ *** HTTP MESSAGE-BODY REMOVED FOR BREVITY *** ]
\r\n
- The browser re-issues the same request that it sent in step 1. However, this time the browser inserts the Authorization: Basic header that includes the user’s credentials.
GET /SomePath/PageOfInterest.aspx HTTP/1.1\r\n
Host: ServerB\r\n
Accept: */*\r\n
Authorization: Basic TG9jYWxVc2VyOkxvY2FsUGFzc3dvcmQ=\r\n
\r\n
- The credentials are valid and the user has permission to access to the requested resource. Therefore, the data that is requested is returned to the user.
HTTP/1.1 200 OK\r\n
Date: Mon, 16 Feb 2004 00:40:37 GMT\r\n\
Server: Microsoft-IIS/6.0\r\n
X-Powered-By: ASP.NET\r\n
X-AspNet-Version: 1.1.4322\r\n
Set-Cookie: ASP.NET_SessionId=zzseaci1a4tyhrymokckmau2; path=/\r\n
Cache-control: private\r\n
Content-Type: text/html\r\n
Content-Length: 44\r\n
\r\n
[ *** HTTP MESSAGE-BODY REMOVED FOR BREVITY *** ]
\r\n
The significance of this communication sample is to demonstrate that in a typical Basic authentication sequence, the Web client will first try to communicate by using anonymous authentication (that is, no Authorization: Basic request header is sent). The server then replies with a response that contains a 401- Access Denied status code and a WWW-Authenticate: Basic response header. Typically, between steps 2 and 3, the browser prompts the user with a dialog box that prompts the user to enter credentials in response to the server's Authenticate: Basic challenge. However, per RFC 2617, most browsers (including Internet Explorer) provide the Authorization: Basic header if the user has already provided the Basic authentication credentials for the specified realm. After you install Security Update MS04-004, Internet Explorer discards the credentials that are passed through the URL, and WinInet no longer has the credentials to forward automatically. Therefore, the user receives a dialog box that prompts the user for Basic authentication credentials.