[2771] in WWW Security List Archive
Re: A problem with Navigator's cache
daemon@ATHENA.MIT.EDU (Steff Watkins)
Fri Aug 23 05:12:10 1996
From: Steff Watkins <Steff.Watkins@Bristol.ac.uk>
To: imd1707@ggr.co.uk
Date: Fri, 23 Aug 1996 08:08:49 +0100 (BST)
In-Reply-To: <Pine.SUN.3.94.960818101642.11552B-100000@ukwsv3> from "Ian Dunkin" at Aug 22, 96 02:31:15 pm
Errors-To: owner-www-security@ns2.rutgers.edu
Ian Dunkin wrote:
=>Some of our users share PCs. Some servers on our internal Web hold
=>documents whose access requires authentication.
=>
=>When a PC Navigator user attempts to access such a page, and
=>authenticates successfully, the document is retrieved and displayed, and
=>cached to their local disk. This user now switches the PC off, and
=>leaves. Another user switches the PC back on, and fires up Navigator.
=>She attempts to access the same document. Navigator pulls it back for
=>her from the cache, without authentication.
=>
=>How might this be addressed?
=>
=>(1) Set `Verify Document' to force reauthentication. However, in the
=>meantime the document has been sitting clear and visible on the local
=>disk for the second user to access directly.
Hello Ian,
the trick here is to force the browser to reload the document, as
authentication is initiated at the server when an attempt is made
to load a protected document.
Though I have not tried doing this myself yet (it is on my evergrowing
list of TODO's), I believe the trick is to get the server to return a
'no-cache' instruction. Having a bridging CGI-type mechanism may help in
this. It would have to send back headers similar to this:
Content-type: text/html
Pragma: no-cache
<html>
...... Document follows ......
This should force the browser NOT to cache the document. I'm not too sure
about the syntax of the Pramga statement though.
This would mean that the document would not be stored in the cahce, and so
would have to be reloaded. This would force the user to 're' authenicate.
=>(2) Get the users to configure Navigator to cache on a protected file
=>system. Here we'd be dependent on them all doing so. Not feasible.
On my version of Netscape (V2.01 X11), you have to click on 'Options',
'Network Preferences' and then 'Cache' to change the location of your cahce...
=>(3) Have the server pre-expire the document. Here Navigator would
=>require re-authentication before retrieving the document again, but,
=>again, in the meantime it has still been sitting clear and visible on
=>the local disk for the second user to access directly.
See the suggestion for section (1) above...
=>(4) Turn the cache off. Not feasible. They'd turn it back on again.
have heard that there is a way to get Netscape to run with a
system wide, unchangeable configuration. Unfortunately, I know nothing
about this.. *8)
=>Is there any way that the server can tell Navigator that it is not
=>allowed to cache a certain document at all?
As before, see section (1) above...
=>Would SSL help? Does Navigator just secure document _transfer_, or, can
=>it also be persuaded to encrypt documents in the cache?
SSL (Secure Sockets Layer) is a method of preventing people from trapping
the transferred documents in transit between the server and the browser.
As such, it would not address the issue of documents being cache.
You say that some of your users share PCs.If this is the case, I would
assume that these users are considered to have the same 'security' level
within your organisation.
At which point, I would say "What's the problem then? Why should two
people with the same security level have to BOTH authenticate to get the
same document? What is to stop one of them saving the file to disk, and
showing the other? etc.. etc.. etc..."
If the problem is that you only want users from your organisation to see a
certain document, then maybe an easier method (for both you and them) is
to restrict the document's directory to access to certain IP addresses
only. This way, you would not have to have a password mechanism, which can
be an administrative strain and is in itself open to security weaknesses.
Just a few thoughts,
Steff
: Steff Watkins, General Computer-type being
: University of Bristol, Clifton, Bristol, AVON, BS8 1TH, UK
:
: RFC-822 : Steff.Watkins@bris.ac.uk
: X-400 : /G=Steff/S=Watkins/O=Bristol/PRMD=UK.AC/ADMD= /C=GB/
: Phone: +44 177 287869 (external) 3046 / 7651 (internal)
