DOCUMENT:Q238647 TITLE :Proxy Caching May Cause Multiple Clients to Receive Same GUID PRODUCT :Site Server; Site Server, Commerce Edition; MCIS PROD/VER:3.0 OPER/SYS:WINDOWS NT ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Site Server version 3.0 - Microsoft Site Server version 3.0, Commerce Edition - Microsoft Commercial Internet System versions 2.0, 2.5 ------------------------------------------------------------------------------- SYMPTOMS ======== Web browser clients might receive the same Globally Unique Identifiers (GUIDs) when accessing Web sites through a proxy that caches HTTP responses. CAUSE ===== A GUID is used to uniquely identify a browser client to a Web server. Depending on the implementation, there are cases where information can unintentionally be presented to a different client that is using the same GUID. This can occur because some Web proxies cache HTTP responses that may inadvertently contain Set-Cookie HTTP headers containing GUIDs that are intended for a single browser client. This caching can cause a second client requesting the same Web page to receive a cached HTTP response with a Set-Cookie header containing a GUID that was solely intended for a previous client. WORKAROUND ========== There are several workarounds for this problem, listed here in order of effectiveness. 1. Install the Site Server logging fix described in the RESOLUTION section of this article. This fix forces the Mss_log and Authfltr DLLs to append the expires header to every HTTP response sent that includes a Set-Cookie header. 2. Use an expires HTTP 1.0 header per RFC 1945. The Expires header specifies the length of time before a page cached on a browser expires. If the user returns to the same page before it expires, the cached version is displayed. Two ways to set the expires header are: use the response object and the custom headers feature in Internet Information Server (IIS). Syntax: Response.Expires [= number] In the Microsoft Management Console for IIS, the HTTP Header Property Sheet can be used to set the "expires" value returned to the browser in the header of the HTML page. To have your Web server send an "expires" header, click Add, and then type the name and value using the criteria explained under the Expires section in http://www.w3.org/Protocols/rfc1945/rfc1945: 10.7 Expires The Expires entity-header field gives the date/time after which the entity should be considered stale. This allows information providers to suggest the volatility of the resource, or a date after which the information may no longer be valid. Applications must not cache this entity beyond the date given. The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time. However, information providers that know or even suspect that a resource will change by a certain date should include an Expires header with that date. The format is an absolute date and time as defined by HTTP-date in Section 3.3. Expires = "Expires" ":" HTTP-date An example of its use is Expires: Thu, 01 Dec 1994 16:00:00 GMT If the date given is equal to or earlier than the value of the Date header, the recipient must not cache the enclosed entity. If a resource is dynamic by nature, as is the case with many data-producing processes, entities from that resource should be given an appropriate Expires value which reflects that dynamism. The Expires field cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource is initiated. User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session. By default, the Expires field does not apply to history mechanisms. If the entity is still in storage, a history mechanism should display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents. NOTE: Applications are encouraged to be tolerant of bad or misinformed implementations of the Expires header. A value of zero (0) or an invalid date format should be considered equivalent to an "expires immediately." Although these values are not legitimate for HTTP/1.0, a robust implementation is always desirable. 3. Set the "CacheControl = Private" HTTP 1.1 header. When CacheControl is set to Private, only private caches will cache the page. This is the default value. Most proxy servers will not cache pages with this setting. Not all proxies are HTTP 1.1-compliant, so this may not work with some. The CacheControl header can also be set in the Response object or by using the custom headers user interface for IIS. Syntax: Response.CacheControl [= Cache Control Header ] NOTE: When you add the Expires header or CacheControl headers, make sure the new files are time stamped. Some proxy-cache mechanisms use logic that checks the time stamp, and if it is less than 24-hours old, it always reads from the cache. If the time stamp is more than 24-hours old, it checks to see if the original file has been modified. It only dumps the cached content if it is both older than 24 hours and has been modified. If the time stamp has not changed, the proxy does not pick up the newer file, even if the file is new. 4. Make sure that automatic cookie authentication is turned off for all but the directories that actually need to send cookies. If Site Server Automatic Cookie Authentication is enabled on the entire content tree including the directories that contain images, a browser that performs a GET request on a GIF with no Site Server cookie in the request header causes the membership authentication filter to automatically try to send the browser a Site Server cookie containing a GUID that uniquely identifies the client. This can cause a cookie containing a GUID to be sent along with an image or other standard HTML document, and the cookie would then be sent to the next user requesting the same cached image or page. RESOLUTION ========== A supported fix that corrects this problem is now available from Microsoft, but it has not been fully regression tested and should be applied only to systems experiencing this specific problem. If you are not severely affected by this specific problem, Microsoft recommends that you wait for the next Site Server service pack that contains this fix. To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information on support costs, please go to the following address on the World Wide Web: http://www.microsoft.com/support/supportnet/overview/overview.asp The English version of this fix should have the following file attributes or later: Date Time Size File name Platform ------------------------------------------------------------- 08/26/99 08:09p 118,032 Authfltr.dll Alpha 07/02/98 03:27p 913 Eula.txt Alpha 08/27/99 06:01p 23,312 Mss_log.dll Alpha 01/27/99 02:56p 80,144 Update.exe Alpha 08/27/99 06:26p 1,868 Update.inf Alpha 08/26/99 08:09p 65,056 Authfltr.dll x86 07/02/98 03:27p 913 Eula.txt x86 08/27/99 06:01p 15,472 Mss_log.dll x86 01/27/99 02:02p 62,544 Update.exe x86 08/27/99 06:26p 1,868 Update.inf x86 This hotfix has been posted to the following Internet location as Alpha.zip and Intel.zip: ftp://ftp.microsoft.com/bussys/sitesrv/sitesrv-public/fixes/usa/siteserver3/ Hotfixes-PostSP2/ProxyCache/ STATUS ====== Microsoft has confirmed this to be a problem in Site Server 3.0, Site Server 3.0, Commerce Edition, and Microsoft Commercial Internet System 2.0 and 2.5. MORE INFORMATION ================ For more information about this vulnerability, see the following Microsoft Web site: http://www.microsoft.com/security/Bulletins/MS99-035.asp Additional query words: duplicate mcis ============================================================================ THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.