[Owasp-browser-security-acid-tests] Preventing PDF Caching over SSL in IE

Dave Wichers dave.wichers at owasp.org
Thu Feb 24 08:00:25 EST 2011


Here is another test case for our browser security suite:  (and the
'solution' that will cause it to have the 'right' behavior.)

 

I know IE claims this is 'by design' but apparently other browsers solved
this problem so it appears solvable.

 

-Dave

 

From: Jon 
Sent: Thursday, February 24, 2011 5:23 AM
To: Mike 
Subject: Re: Preventing PDF Caching over SSL in IE

 

The bug w/ IE is a "Cache-control: no cache, no store". This will stop IE
from caching any Content-Disposition that IE doesn't handle natively, which
could be PDFs. "Cache-control: no store" and "Cache-control: no store, no
cache" will cause a pop-up error to be displayed but the PDF will also be
displayed. This pop-up error may be IE and/or Reader centric, dunno.

Jon


On 2/24/11 1:28 AM, "Mike" wrote:

While onsite teaching a student asked how to keep PDFs from caching in IE
and still view it. He wants to 1) display a PDF in any browser including IE
2) Transmit over HTTPS and 3) not cache or store the file. This seemed
pretty reasonable and exactly what the pragma and cache-control headers are
for, but I did some research and it appears that IE doesn't allow that to
happen. Before I stand up an HTTPS server to test solutions, I'm wondering
if any of you have found a solution to his problem or seen it manifest. 
 
IE has, in versions as recent as IE 8, a "feature" that prevents any file,
including PDFs from being downloaded and displayed without first caching
them. Note that this appears to be an IE issue; FF behaves correctly.
 
Below are some references that I found that describe IE's behavior.
 
1)      http://support.microsoft.com/kb/323308 (Internet Explorer file
downloads over SSL do not work with the cache control headers)

This link describes the issue. The articles suggests modifying the user's
registry settings (even for IE7 & 8) to get it to work. Not exactly
practical.

 
Quoting:
 
When you try to open a Microsoft Office document or a PDF file by typing an
HTTPS URL for the document in the Address bar of Internet Explorer 6 Service
Pack 1 (SP1), you may receive the following error message: Unable to
download. This issue occurs if the server sends a "Cache-control:no-store"
header or sends a "Cache-control:no-cache" header.
 
 
2)      http://support.microsoft.com/kb/316431 

This link is a little old (2007 IE5&6) and off target, but it is related in
that it explains what is going on between IE and Adobe Acrobat Reader and
that this behavior is by design. 
 
Quoting:
 
In order for Internet Explorer to open documents in Office (or any
out-of-process, ActiveX document server), Internet Explorer must save the
file to the local cache directory and ask the associated application to load
the file by using IPersistFile::Load. If the file is not stored to disk,
this operation fails. 

When Internet Explorer communicates with a secure Web site through SSL,
Internet Explorer enforces any no-cache request. If the header or headers
are present, Internet Explorer does not cache the file. Consequently, Office
cannot open the file.
 
Web sites that want to allow this type of operation should remove the
no-cache header or headers.
 
This behavior is by design.
 
 
3)
http://blogs.msdn.com/b/ieinternals/archive/2009/10/02/internet-explorer-can
not-download-over-https-when-no-cache.aspx () 

KB 316431 is pretty old, but From eric law's more recent blog (2009-2011)
confirms that this is expected: "if a user tries to download* a file over a
HTTPS connection, any response headers that prevent caching will cause the
file download process to fail." The rest of the article is looking at
enabling manual downloads instead of viewing a file without caching. It
discusses strategies for getting files to download including the weird
"no-store, no-cache" vs "no-cache, no-store" behavior. It also discusses
some very recent fixes for IE8 and 9 that may or may not be relevant.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-browser-security-acid-tests/attachments/20110224/327b5ced/attachment.html 


More information about the Owasp-browser-security-acid-tests mailing list