RE: Prevent caching of pdf files

> From: bsec [mailto:bsec@xxxxxxxxx] 
> Sent: Friday, December 05, 2003 5:33 PM

> Currently on a secure Internet application we use the 
> "Cache-Control: No Cache" header to prevent information from
> caching on client machines.  We would like to begin to provide pdf
> files via our application; however, there is a known issue with
> accessing pdf files with IE 6.0 sp1 when the no-cache header is
> used.  (Please refer to 
> http://support.microsoft.com/default.aspx?scid=kb;en-us;812935
> for details.)  As we have no control over the client machines 
> accessing our application, is there another way to prevent pdf
> files from being automatically stored on the clients without using
> the no-cache header?

My personal choice would be to avoid PDF files like the plague, as I think
they're nearly as bad an information-representation choice as HTML email, in
terms of benefit-cost ratio.  But if you're determined...

(I'm also assuming here that the threat you're trying to address is an
attacker retrieving documents from the cache at a later date, not a hostile
user trying to keep copies of documents being served, which is of course
impossible to prevent.  So we're assuming a cooperative user and an
otherwise normally-functioning user agent.)

The advisory only mentions the Cache-Control header and the "Do Not Save
Encrypted Files" option.  It sounds like there's a generic issue with
caching - that IE 6sp1 simply will refuse to download or render PDFs over
SSL if caching is disabled - in which case you're out of luck.  (I suspect
the problem is that IE caches the PDF file and then invokes the Acrobeast
ActiveX control against it, or some such thing.)

However, you could try some alternate methods of discouraging caching just
in case it's actually an issue specifically with Cache-Control and "Do Not
Save".  See chapter 13 of RFC 2616 (HTTP/1.1) for full information.

For example:

1. HTTP/1.1 specifically requires that a cache invalidate any cached entity
referred to by a URL in response to a request using the PUT, DELETE, or POST
method (13.10).  In effect, that means that POST should always fetch a fresh
version of a document, not a cached one.  That doesn't stop a cache from
caching the result of a POST request.  However, you might expect a
well-written cache to not cache the results of a POST, on the grounds that
there probably won't be a subsequent GET for the same entity.  I have no
idea whether IE does, but I'd give this a try first.

2. HTTP/1.1 specifies that no HTTP/1.1-compliant cache mechanism should
treat an HTTP/1.0 response to a GET request with a query URL (one containing
a "?" character) as fresh, unless that response contains expiration
information, because it was common practice in HTTP/1.0 for query-URL GET
requests to have side effects (13.9).  However, I hope your server is
HTTP/1.1, not 1.0, so this probably doesn't help.  (Anyway, I have no idea
whether IE respects this rule, or fully complies with caching freshness
rules.)

3. HTTP/1.1 caching incorporates an expiration mechanism.  HTTP/1.1 allows a
server to specify an expiration time in the past for a response to force a
cache to validate any cached copy before returning it to the client
(13.2.1).  A "lazy" cache might simply avoid caching any already-expired
response, since it will have to validate it anyway.  I don't know what IE
does.

In the end, though, Cache-Control is the mechanism designed into HTTP/1.1
for preventing caching, and it's broken in IE6sp1.  (Who would have
thought?)  Trying to trick the browser into not caching the response through
other means is klugy at best and unlikely to work in the long run.

Hmm... It appears that some browsers offer Javascript methods to remove
cache entries.  I haven't investigated further, but you might try some
Javascript references for more information.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus