The inclusion of Forms Authentication in the .NET Framework has made it significantly easier to protect web pages by requiring users to log in to a web application.  One problem with Forms Authentication is browser caching of secured pages.  After a user logs out of an application, they can still review secured pages by using the browser's Back button.  The user is only looking at local copies of pages they viewed while previously logged in, but this can be undesirable in many instances, and present a genuine security risk.

In this article, we will explore a few small coding changes you can make to prevent users from reviewing secured pages after logout.

In order to speed up the Internet experience and reduce load on web servers, all browsers keep locally cached copies of the visited pages for a specified amount of time.  Users can set a time limit or space limit in their browsers for the page cache, but few do.  When a browser requests a page from a web server, it checks the timestamp on that page to determine whether the content has changed.  If the timestamps match, the browser renders the local copy; if the timestamps differ, the browser requests the page again.  For the site visitor, it's usually good that the browser has a local copy of any page that does not change frequently, since it's faster to load locally than download everything again.  However, for the webmaster, this can be a problem.  When users log out of a site protected by Forms Authentication, they may still review the local copy of the pages they visited.  This can be a security issue, as well as a nuisance.  The timestamp of pages with dynamic content does not change when the page is loaded, since the timestamp is read from the file system, not set when the page is requested (note that pages with querystring parameters are not usually cached by browsers, as it is evident they are dynamic).  As such, browsers may keep displaying the same old content over and over, instead of requesting fresh content.

Another security problem can arise if proxy servers are in use.  When a browser requests a page through a proxy server, the proxy server compares the timestamp of the requested file to see if it has changed.  If the timestamps match, the proxy server sends its locally cached copy back to the browser.  In the past, if two users requested the same page, they may have received identical copies of the page.  If the page contained dynamic content for one user, another user may have seen something they should not have seen.  Most proxy servers seemed to have remedied this issue by comparing the user who requested the page, but that doesn't mean every ISP or corporation is using a recent version of its proxy server.

Fortunately, web programmers can send three HTTP headers to the browser that specify how long a page should be cached by the browser or proxy server, if at all.  These headers can be set in the HTML code, or set in directly in server-side code.  The three useful headers are Expires, Pragma: no-cache, and Cache-Control.

Information on using all three headers and how Internet Explorer supports them can be found at
http://support.microsoft.com/kb/q234067/.

Expires

The Expires header is part of both the HTTP 1.0 and 1.1 specifications, and should be supported by every major and minor browser in use.  Per the specification, the Expires header does not prevent local caching of the resource, but rather tells the browser to check for a new version after a particular date.  The Expires header is set to either an absolute date and time to indicate the expiration of the page's content, or a value of -1 to indicate immediate expiration. For your dynamically generated pages, it's suggested to set Expires to a value of -1; for static pages, or ones that change infrequently (daily or longer), it's suggested to set Expires to a specific date value slightly before the next expected update.

Also per the specification, using the browser's Back button should display pages even past their expiration date.  As such, setting the Expires header is not enough, but every page should have an Expires value.

Pragma: no-cache

This header is part of the HTTP 1.0 and 1.1 specifications.  The Pragma: no-cache header is not meant to control browser caching of server responses, but is intended to signal proxy servers to expire the request and properly forward any other similar requests to the web server.

Recent versions of Internet Explorer support the use of Pragma: no-cache to expire responses, but this implementation is not supported by version 5 or earlier, and may not be supported by many other browsers, either.  You may see this header in a number of examples online, but since it is actually part of the request, it is recommended you do not use it in the response stream.

Cache-Control

This header is part of the HTTP 1.1 specification only.  Most browsers and proxy servers in use today should support HTTP 1.1, but the browser option can be configured by the user.  It's probably safe to assume that devices contacting your site support this header, but you cannot count on that to be the case.

You can set Cache-Control to several values:

• Public: Content can be stored in public shared caches.  Good for your home page and any other publicly available pages.
• Private: Content can be stored only in private cache.  Proxy servers should not store the content unless they support private caching.  Useful for pages with user interaction; a better method is No-store (see below).
• No-cache: Content may not be cached.  This is the highest security setting, and should be used for all pages that contain sensitive information.
• No-store: A better form of Private.  Content may be cached for the length of the session, but not archived.

All applications should set the Cache-Control of their pages.

Any of these three headers can be set in the <head> section of your web page, as shown below:

Listing 1: HTML HTTP Header Tags

<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="-1">
<meta http-equiv="CACHE-CONTROL" content="NO-CACHE">

You will need to add these headers to every page, and set their values accordingly.  Internet Explorer versions 4 and 5 do not support the Cache-Control http-equiv tag, so Microsoft recommends setting this value as part of the Response object in server-side code.

In ASP.NET, a class named HttpCachePolicy has been introduced, which gives finer control over expiration and caching of content.  It is recommended that a developer use the HttpCachePolicy class rather than the Response.AddHeader() method to set caching policies.

Listing 2: HttpCachePolicy Properties

Response.Cache.SetExpires(DateTime.Parse("6:00:00PM"))
Response.Cache.SetCacheability(HttpCacheability.Private)

Note that the SetExpires() method only accepts a DateTime value.  Instead of passing -1 as a value, you will need to pass an absolute time (as above), or use the DateTime.Now property to pass in the current time.  According to the HTTP specifications, all absolute times in these headers should be set by Greenwich Mean Time to avoid any strange behavior when crossing time zones.

Additional properties and methods for the HttpCachePolicy class are detailed in the documentation for the 1.1 Framework and Beta 2 Framework.

An easy way to ensure these properties are set on every page is to create an abstract page class that inherits from the intrinsic Page class, and set these properties in the Page_Load or Page_Init handler of the abstract page class.  Then, every page in your application should inherit the abstract page.  This is a much easier way than copying HTTP headers into every ASPX page.

A simple coding change to a base page class can help ensure users cannot review pages after they log out of a website protected with Forms Authentication.  When used with Session.Abandon and proper expiration of the FormsAuthenticationTicket, you add additional security to your site, and help protect your user’s information.