[8424] in bugtraq

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

Re: Form insecurity in Netscape

daemon@ATHENA.MIT.EDU (Mark R. Bowyer - Sun UK - Sun Deve)
Thu Nov 5 13:11:51 1998

Date: 	Wed, 4 Nov 1998 19:55:41 +0000
Reply-To: "Mark R. Bowyer - Sun UK - Sun Developer Relations" <Mark.Bowyer@UK.Sun.COM>
From: "Mark R. Bowyer - Sun UK - Sun Developer Relations" <Mark.Bowyer@UK.SUN.COM>
X-To:         kelani@KELANI.COM
To: BUGTRAQ@NETSPACE.ORG

>From: kelani <kelani@KELANI.COM>

>In the Netscape Navigator 3.x and Communicator 4.x installations at my
>school, where all users share a common login, Navigator seems to write a
>'nsformXX.tmp' file when a user fills out a form on a webpage. This file
>contains the fields the user filled in as plaintext, and looks like this:

I thought this was quite well known - I've worked around Navigator crashes while
I was filling in a series of forms by extracting some of the data from these
files.  My Solaris 7 system has 2 such files right now:

-rw-------  1 markbo  sunsoft   2764 24 Sep 1998  /tmp/nsform360A35344F93D14
-rw-------  1 markbo  sunsoft  15828 20 Oct 1998  /tmp/nsform362C51A80A84F2D

The perms make this fairly safe, as long as the *machine* is secure.  I'm pretty
sure the code tries to maintain these files somehow, as I've filled in way more
forms than this since September.  Maybe if Communicator crashes before it gets
round to cleaning up it leaves them?  Do you exit Netscape before you shut down?

The format is standard multipart/form-data, as would be passed to your CGI code
where this *your* form.  The data is created in-file before it's passed back up
to the web server, it seems.

I checked the contents of these files on my system, and the one occurence of a
Password field in them is either encoded or encrypted.  From the look of it it's
"basic" encoding, so I wont put an example here... ;O)

The encoding scheme used is pretty simple.  The description of the technique in
the official standard is pretty obfusicated, but I managed to write some code to
decode the name:password pair back to original text so that MOOs could use
"basic" security from web browsers to allow web-based access to them (for
MOOtiny and the newer MOOs based on our code).

On OSes without proper security between users, then, I'd say this was indeed a
potential problem for personal data.


-------My opinion - Not sane, intelligent or necessarily useful-------
o o                                      mailto:Moredhel@earthling.net
/v\ark R. Bowyer.  http://i.am/Moredhel  mailto:Mark.Bowyer@UK.Sun.COM
`-'                       Oh My God!  They killed init!  You Bastards!

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