When you install the Security Update in Microsoft Security Bulletin MS04-004 on your computer, some of your Web applications that pass credentials through a URL may break.This article discusses several methods to work around this problem and discusses the limitations of each method.
This article discusses how to pass the user credentials through the URL for Single Sign-On (SSO) by using Basic authentication. When you install the Security Update in Microsoft Security Bulletin MS04-004, you cannot pass credentials through the URL.
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:
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:
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.
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\nHost: ServerB\r\nAccept: */*\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.
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.
Use one of the following methods to work around this problem. The proposed approach in this section refers to three hosts: ServerA, ServerB, and the Web client. Where ServerA is the name of the requested page, and ServerB is the name of the server where the requested page is stored.
Note Because the changes that are made in Security Update MS04-004 apply only to Microsoft Windows versions of Internet Explorer, the Web client is assumed to be a version of Internet Explorer that has been updated with Security Update MS04-004.
You can download code samples of the various workarounds that are suggested in this article.The following file is available for download from the Microsoft Download Center: Download the Code Samples package now.For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:
119591 How to Obtain Microsoft Support Files from Online Services
Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file.
Method 1: Use the XMLHTTP object
Use the XMLHTTP object to make an intermediate request in client-side script that is running on the Web client, instead of relying on Internet Explorer to automatically redirect when it receives the 302 (redirect) response from ServerA. The XMLHTTP object exposes several properties that allow developers to collect data from the HTTP Response headers, the QueryString, or the Message-body of the HTML document.
(MSXML) must be available for scripting on the client (MSXML 3.0 is included with Microsoft Windows 2000 and later, and is included with Internet Explorer 6.0 and later).
ServerA must support modification to its configuration. This modification permits ServerA to send the Web client to a page that loads the XMLHTTP object. The XMLHTTP object intercepts the redirect message instead of trying to process the redirect message as it before you installed Security Update MS04 004.
A bug in MSXML prevents this solution from working without additional configuration. This bug has been fixed. However, Internet Explorer clients that have installed the Security Update MS04-004 require an updated version of msxml?.dll.For additional information about the updated version of msxml?.dll, click the following article number to view the article in the Microsoft Knowledge Base:
832414 XMLHTTP call fails for URLs with embedded user credentials
Method 2: Use a server-side application that can modify the HTTP data stream before script execution
Use a server-side application that can modify the HTTP data stream before script execution (such as an ISAPI filter or a .NET HttpModule) on ServerB to intercept the credentials that are transmitted by the Web client through another section of a valid HTTP request, and then generate a valid Authorization: Basic header to pass down to the Web server for authentication.
ServerA must support modification to its configuration (to send the Web client the credentials in another section of the response, such as the QueryString or in a Cookie. Therefore, the Web client can transmit those credentials to ServerB for the ISAPI filter or HttpModule to intercept)
ServerB must support the server-side application, such as ISAPI filters or .NET HttpModules, that is used in this workaround.
Method 3: Use a server-side component such as WinHttp or ServerXMLHTTP
Use a server-side component such as the WinHttp object or the ServerXMLHTTP object inside an ASP page or an ASPX page on ServerA to retrieve the content from ServerB directly, (that is, on behalf of the user), and then return that content to the Web client. In this scenario, the Web client never communicates with ServerB.
The WinHttp.WinHttpRequest.5.1 Prog ID must be available on ServerA. By default, WinHttp.WinHttpRequest.5.1 is included with Microsoft Windows 2000 SP3, Microsoft Windows XP SP1, and Microsoft Windows Server 2003.
WinHttp.WinHttpRequest.5.1 expects ServerB to return completed content to the Web client. In this scenario, the Web client has the version of Internet Explorer installed that has been updated with Security Update MS04-004. If this Web client expects to conduct synchronous communications with ServerB (through an ActiveX control or a Java applet), this solution may not work.
Microsoft does not recommend this workaround because the performance of ServerA will affect the functionality of the Web client if the Web client has the version of Internet Explorer installed that has been updated with Security Update MS04-004.
Method 4: Use a custom client-side application
Use a custom client-side application such as an ActiveX control that calls the WinInet API or the WinHttp API, or a .NET Windows Form control that uses the System.Net.Sockets namespace, that you can create an instance of in client-side code in the browser. This custom object must be able to establish a TCP connection, and must be able to transmit well-formed HTTP(S) messages (including generating an Authorization: Basic request header).
ActiveX solution: Users must have permission to install ActiveX controls on their computer.
ActiveX solution: Security settings in Internet Explorer must allow execution of ActiveX applications.
.NET WinForms solution: The Microsoft .NET Framework must be installed on the Web client.
Users in managed environments may not be able to modify their download and execution settings to allow ActiveX controls or .NET WinForms controls.
WinHttp (called directly through COM, or through the .NET Framework) uses a different set of APIs than WinInet (that is used by Internet Explorer). Therefore, any authentication in a client-side application must occur for each request that is sent to the Web server.
.NET WinForms solution: Before executing the client-side control, you must configure the .NET Security feature on each Web client.
.NET WinForms solution: The only way to remotely verify that the .NET Framework is installed on an unmanaged Web client is to query the HTTP User Agent string that is provided by Internet Explorer. However, because this value can be changed with a registry setting, do not consider this kind of detection authoritative.
The following file is available for download from the Microsoft Download Center: Download the Samples.exe package now.For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:
119591 How to Obtain Microsoft Support Files from Online Services
Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help to prevent any unauthorized changes to the file.For more information, visit the following Microsoft Developer Network (MSDN) Web sites: