When a browser requests a page from a Web server it stores a copy of the files and images it receives in its cache -- a directory on the computer's hard drive. This is done to improve response times if the page is requested again and to reduce network traffic. Unfortunately, this creates a security problem when a user requests sensitive files or information, such as account information or a management report, from your Web server. If the user is on a public computer in an Internet cafe for example, the sensitive data will remain on the computer after they leave. There are risks even if the user is located on your internal network. The sensitive data can be legitimately included in a nightly backup, thus leaking the data on to the backup tape. It is the Web developer's role to prevent the inadvertent release or retention of sensitive information.
Many Web developers assume that by adding the following Meta tag to a Web page it will be marked as un-cacheable and thus solve the problem of browsers storing sensitive documents:
<![CDATA[<HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">]]>
Unfortunately, only a few browser caches and even fewer proxy caches take any notice of this Meta tag. However, HTTP 1.1 introduced a new class of HTTP headers -- cache-control response headers. By using these headers you can control how both browser caches and proxies handle Web
pages and ensure that sensitive documents are not cached. HTTP headers are generated and sent by the Web server before the actual HTML content of a page, and are only seen by the browser and any intermediate caches.
The two key cache-control response headers are:
- NO-CACHE: This directive tells the browser that it has to request the document from the server for validation every time before releasing a cached copy.
- NO-STORE: This directive instructs remote and local, shared and non-shared caches not to store a copy of the document under any conditions.
Note that no-cache does actually allow a copy of the document to be stored whereas no-store prohibits it. As you might expect, Internet Explorer (IE) and Mozilla browsers have different implementations of these cache-control directives.
Both browsers will cache a document requested over an HTTP connection that has the "no-cache" directive set. Mozilla will not cache any pages by default over an HTTPS connection, whereas Internet Explorer will, unless the user has enabled the "Do not save encrypted pages to disk" option. A Mozilla browser never stores documents set with the "no-store" directive, but Internet Explorer only fully follows this directive when the page is requested over an HTTPS connection. So the only way of ensuring that your sensitive documents and pages are not cached without requiring your users to manually set any IE options is to use the "no-store" directive over an HTTPS connection. All browsers supporting HTTP 1.1 will support this directive.
You can set the no-store response header in IIS by opening the HTTP Headers property sheet for a Web site or preferably for a folder within a Web site as it not a good idea to use this header globally across an entire Web site but purely for content that absolutely must not be cached on the client.
About the author
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for SearchSecurity's Web Security School and, as a SearchSecurity.com site expert, answers user questions on application and platform security.
