[1297] in WWW Security List Archive

home help back first fref pref prev next nref lref last post

Re: caching protected documents

daemon@ATHENA.MIT.EDU (=?iso-8859-1?Q?Jani_Gr=F6nberg?=)
Thu Dec 21 06:56:51 1995

From: =?iso-8859-1?Q?Jani_Gr=F6nberg?= <Jani.Gronberg@tele.inet.fi>
To: "'www-security@ns1.rutgers.edu'" <www-security@ns1.rutgers.edu>
Date: Thu, 21 Dec 1995 11:11:37 +-200
Errors-To: owner-www-security@ns2.rutgers.edu

From "Brain 21":

>On Wed, 20 Dec 1995, Jeff Weinstein wrote:

> that the "authentication key"(password) was somehow being saved by
> netscape.  In fact it was not, and what he was seeing was the result =
of
> a minor bug in the caching code, displaying a page that should have
> been thrown out of the cache.  If the server was ever contacted again,
> a real username and password would have to be typed to access =
protected
> pages.
>=20
	<description of the problem deleted>

>What does this mean??  This is NOT necessarily a cacheing problem!!!

 	<snip>

We have a similar problem with our service related to the cookie =
mechanism. When you first authenticate yourself to a our secure server, =
your userid and password (and additional data) are saved to a string =
called cookie. Your browser stores this cookie and sends it with every =
HTTP request to that particular server. This way you don't have to type =
your password again every time you access a protected page.

The problem with the cookie is that it gets saved to your disk, and is =
not wiped when Netscape closes. I tried this with our own service by =
typing in my user information, fetching some pages, closing Netscape and =
restarting it. I can now get to the protected area without typing my =
password.

We have found two ways to work around this:
1) Our service includes a logout-button, which invokes a script that =
clears the cookie. Customers are strongly encouraged to use this to quit =
using the service.
2) The cookie has an expiration time after which it's no longer valid =
(currently set to 4 hours).

We encrypt the cookie string to prevent anybody from discovering the =
userid/password pair from disk. If the site you are accessing has a =
similar mechanism, your problem might be caused by this.

Hope this helps,

Jani Gr=F6nberg / Telecom Finland


home help back first fref pref prev next nref lref last post