[1281] in WWW Security List Archive
Re: SECURITY ALERT: Password protection bug in Netscape 2.0b3
daemon@ATHENA.MIT.EDU (David W. Morris)
Wed Dec 20 05:42:51 1995
Date: Tue, 19 Dec 1995 23:21:18 -0800 (PST)
From: "David W. Morris" <dwm@shell.portal.com>
To: Wayne Wilson <wwilson@umich.edu>
cc: Jeff Treuhaft <jeff@netscape.com>, www-security@ns2.rutgers.edu
In-Reply-To: <Pine.PCW.3.91.951219095114.15734A-100000@ncollier.med.umich.edu>
Errors-To: owner-www-security@ns2.rutgers.edu
On Tue, 19 Dec 1995, Wayne Wilson wrote:
> On Mon, 18 Dec 1995, Jeff Treuhaft wrote:
> document with it. That way, when the browser is exited, the session key
> is lost and the cached document is now unreadable ... but then you still
> have to have a way to delete from the cache ... In the end, it would
> seem simpler to just not cache protected documents in the first place.
>
Not really, some protected pages are the result of a transaction and
should be visable via the BACK button of the browser in the session
history.
For starters, there are two kinds of 'caching' performed in a browser:
1. Backing store for the session history
2. Backing store for minimization of network reload time
I suspect that many browsers are implemented to combine these two kinds of
need into a single cache. They need to be isolated so that both good
usability and privacy can be handled while optimizing network performance.
The session history is a kind of virtual paper which has the most value if
the content isn't altered. After all, if you have a real piece of paper
on your desk it remains a faithful record unless it is explictly altered.
The virtual paper of the history should follow the same paradigm w/o respect
to the protected nature of individual pages.
If you accept that fundamental design premise, then it may be possible to
handle protection of content with some rules like:
1. Never save a protected page beyond the scope of a single execution of
the UA program.
2. Never use DASD for backing store for history purposes for an
authorized document. If memory cache space is exhausted, then
the history is lost (different UA's could handle error recovery
in terms of advising the the user, etc.)
This of course assumes that the user doesn't leave their machine 'logged'
in. There is nothing we can do to help such users.
There is a problem for the UA in determining with certainty that a page
is protected. As I read the HTTP draft, if the UA guesses that a request
will require authentication (e.g., based on URL path) it can provide the
authentication information w/o waiting for the challenge eliminating a RTT
but not really knowing if authentication was required.
But erring on the safe side, the above steps will prevent a correctly
running UA from leaving a record on DASD or protected information while
continuing to maximize performance and provide a well behaved user
interface.
This will still leave some information providers concerned. I have recently
learned of a major bank which is concerned that private information might
be left in memory in the event of a UA abort which results in a core file.
They are hacking the result by sending the data under cover of an error
response based on the expectation that:
1. UAs will choose to display content associated with a 5xx error
2. UAs will not include such responses in the session history.
While I can think of a lot of reasons why this is probably misdireected
concern, we probably need to provide response codes or headers which
prevent inclusion of content in the history.
Ultimatately, applications via their servers need two levels of privacy
control:
1. Don't record on external storage media
2. Don't include in session history
so that UAs do not need to guess about what should be protected and how.
Dave Morris
