Problem with Microsoft Security Bulletin MS04-004Microsoft 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:
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:
For additional information about Microsoft Security Bulletin MS04-004, visit the following Microsoft Web site:
SSO implementationThe 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
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.aspThis 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
ServerB, and then provides credentials when challenged.
Sample sequenceThe 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:
- The browser issues an anonymous request to the Web server.
GET /SomePath/PageOfInterest.aspx HTTP/1.1\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
WWW-Authenticate: Basic realm="ServerB"\r\n
Date: Mon, 16 Feb 2004 00:38:11 GMT\r\n
[ *** HTTP MESSAGE-BODY REMOVED FOR BREVITY *** ]
- 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
Authorization: Basic TG9jYWxVc2VyOkxvY2FsUGFzc3dvcmQ=\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\
Set-Cookie: ASP.NET_SessionId=zzseaci1a4tyhrymokckmau2; path=/\r\n
[ *** HTTP MESSAGE-BODY REMOVED FOR BREVITY *** ]
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:
Method 1: Use the XMLHTTP objectUse 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 executionUse 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 ServerXMLHTTPUse a server-side component such as the WinHttp object or the ServerXMLHTTPobject inside an ASP page or an ASPX page on ServerA to retrieve the content from ServerBdirectly, (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 applicationUse 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.
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:
For more information, visit the following Microsoft Developer Network (MSDN) Web sites:
ID do Artigo: 837104 - Última Revisão: 17 de set de 2011 - Revisão: 1