Article ID: 263730
Article Last Modified on 11/4/2002
APPLIES TO
- Microsoft Site Server 3.0 Standard Edition
This article was previously published under Q263730
SYMPTOMS
On a Web site that authenticates with Site Server 3.0 HTML Forms Authentication, users may inadvertently be authenticated under another account. This can occur even when the user has not attempted to log on.
CAUSE
This problem can occur because the HTML Forms Authentication method uses a cookie that is presented by the client browser. Site Server sets this cookie when a valid user authenticates, and by default, reissues this cookie every 60 seconds.
Certain intermediary proxies and caches on the Internet may cache Web server responses that contain Set-Cookie headers, which are then returned to a different user. Because Site Server HTML Forms Authentication uses a cookie to authenticate users, this can cause a user to accidentally (or intentionally) impersonate another user by receiving a cookie from an intermediary proxy or cache that was not originally intended for them.
WORKAROUND
To work around this issue, use one of the following methods:
Method 1
If the site does contain data of a sensitive nature, then run the site over SSL. This ensures that the cookies cannot be seen by other users (either accidentally or deliberately). This also stops intermediary proxies and caches from caching the response, because only the requesting client can decode the encrypted response from the Web server. This is the most secure method.
Method 2
Set HTML Forms Authentication so that is does not reissue the FormsAuth cookie. To do this, use the following command line on the server:
PMAdmin Set Master /FormsAuthTimeout:Off
NOTE: If you use this command line, and it does not appear to change the setting, locate the HKLM\SOFTWARE\Microsoft\Site Server\3.0\P&M\APP registry key and make sure that the FormsAuth Use Inactivity Timeout value is set to 0.
This is the least secure method, because there is an increased chance that a malicious user may intercept the FormsAuth cookie and use it to deliberately impersonate another user for the duration of the session. If this is a concern, use the SSL method.
If you use this method, the only time a FormsAuth cookie is issued is when the user's credentials are first verified. The Set-Cookie header is part of a "302 - Found" response, which should not be cached. (For additional information, see the "More Information" section of this article.) However, for extra security, you can add headers to the page that issues this first cookie to ensure that the response is not cached. To do this, perform the following steps:
- Open the Microsoft Management Console (MMC) for Internet Information Server. Locate the page that verifies the users credentials. By default, this is the Verifpwd.asp page, which is located in the _mem_bin virtual directory.
- Right-click the page, and then click Properties.
- Click the HTTP Headers tab, and in the Customer HTTP Headers section, click the Add button. In the Custom Header Name field, enter Expires, and for the Custom Header Value, enter Wed, 01 May 1996 12:00:00 GMT.
- Repeat step 3, and enter Cache-Control in the Customer Header Name field, and enter private for the Customer Header Value.
NOTE: Because the FormsAuth cookie is not automatically reissued, the user session times out regardless of whether the user is active or not, which requires the user to re-authenticate in the login page. This can be minimized by increasing the session length. This information is documented in the Site Server online documentation at the following location:
Personalization and Membership P&M Operations Guide/Configuring Membership Server Elements/Configuration the Authentication Service/Limiting Session Length
Method 3
For every page that may set this cookie, make sure that the headers stop intermediary proxies and caches from caching the responses. To do this, perform the following steps:
- Open the Internet Information Services Management Console and navigate to the starting node where HTML Forms Authentication is in place. (This is the site level if the entire site is restricted, or a subfolder if only certain areas are restricted.)
- Right-click this node, and than click Properties.
- Click the HTTP Headers tab. In the Customer HTTP Headers section, click the Add button. In the Custom Header Name field, enter Expires, and for the Custom Header Value, enter Wed, 01 May 1996 12:00:00 GMT.
- Repeat step 3, and enter Cache-Control in the Customer Header Name field, and enter private for the Customer Header Value.
NOTE: If you use this method, all images under this level will not be cached. This can cause an extra load on the Web server. If the images do not need to be restricted and do not require personalization, you can use the following method to allow them to be cached:
- Move all images so that they are in or under a separate Images folder.
- In the MMC, right-click the Images folder, and then click Properties.
- On the Membership Authentication tab, click to select the Allow anonymous check box.
- In the Security Support Providers section, make sure that HTML Forms Authentication option is not selected. You can do this by selecting Other Password Authentication and clearing the two options beneath it. This stops the FormsAuth cookie from being reissued when accessing this content.
- On the HTTP Headers tab, delete the two custom headers that were added previously. This allows the content to be cached.
MORE INFORMATION
The following excerpts are from RFC 2616, which specifies Hypertext Transfer Protocol - HTTP/1.1:
10.3.3 302 Found
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
13.4 Response Cacheability
... If there is neither a cache validator nor an explicit expiration time associated with a response, we do not expect it to be cached, but certain caches MAY violate this expectation (for example, when little or no network connectivity is available)...
However, certain intermediary caches or proxies on the Internet may be very aggressive in their caching, and store and return these pages without the appropriate headers stating they may do so. This information also implies that the page may be returned from the cache during periods of little or no network connectivity, which is undesirable with cookies intended for user identification. For this reason, it is more secure to add headers to explicitly deny the caching of these pages. These recommendations are true for any page that sets cookies that are not intended for general re-use.
ASP pages may also set headers in scripts by including the following code at the start of the page:
<% Response.AddHeader "Expires", "Wed, 01 May 1996 12:00:00 GMT" %>
<% Response.AddHeader "Cache-Control", "private" %>
Microsoft Proxy Server does not cache any pages that contain a Set-Cookie header.
Steps to Reproduce this Problem
- Client A requests a page that requires authentication.
- Client A is redirected to the logon page.
- Client A enters their account details and logs on.
- The server responds by setting the FormsAuth cookie and redirecting Client A to the original page.
- As the valid, now authenticated Client A browses the Web site the FormsAuth cookie is reissued every 60 seconds with the content being returned at the time.
- An intermediary proxy or cache captures and stores this content as it is returned, including the Set-Cookie header.
- Client B, which goes through the same intermediary proxy or cache, requests the same content that was stored in the previous step.
- The intermediary proxy or cache returns the stored content, including the Set-Cookie header, to Client B. The FormsAuth cookie intended for Client A is now set on Client B.
- When Client B makes requests to the Web server, it presents the FormsAuth cookie that was erroneously returned to it by the intermediary proxy or cache.
REFERENCES
For additional information, click the article number below to view the article in the Microsoft Knowledge Base:
228991 How to Create and Install an SSL Certificate in IIS 4.0
Additional References:
RFC1945 - HTTP/1.0
RFC2109 - HTTP State Management Mechanism
RFC2616 - HTTP/1.1
Keywords: kbfix kbprb KB263730
