Proxy Caching May Cause Multiple Clients to Receive Same GUID

ID: Q238647

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.

RESOLUTION

To resolve this problem, obtain the latest service pack for Site Server 3.0. For additional information, please see the following article in the Microsoft Knowledge Base:

Q219292 How to Obtain the Latest Site Server 3.0 Service Pack

WORKAROUND

There are several workarounds for this problem, listed here in order of effectiveness.

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.

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.

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.

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.

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. This problem was first corrected in Site Server 3.0 Service Pack 3.

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

Keywords : SS3SP3Fix
Version : winnt:2.0,2.5,3.0
Platform : winnt
Issue type : kbbug