[1761] in WWW Security List Archive

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

Re: Capturing E-Mail Address of

daemon@ATHENA.MIT.EDU (Marianne Mueller)
Sun Mar 31 16:01:49 1996

Date: Sun, 31 Mar 1996 09:33:42 -0800
From: mrm@doppio.Eng.Sun.COM (Marianne Mueller)
To: Matthew_Lewis@cpqm.saic.com
Cc: www-managers@lists.stanford.edu, www-security@ns2.rutgers.edu
In-Reply-To: <n1384180202.95089@cpqm.saic.com> (Matthew_Lewis@cpqm.saic.com)
Errors-To: owner-www-security@ns2.rutgers.edu

From a Java applet, these browser properties are visible to a
Java-powered browser (that term refers to a browser that implements
the java.* APIs) 

    java.version
    java.vendor
    java.vendor.url	(the advertised URL of the vendor of this browser)
    java.class.version
    os.name		(OS that this client is running on) 
    os.arch		(architecture of the computer running the browser)
    os.version	
    file.separator	(eg "/" or "\")
    path.separator
    line.separator

These properties are not visible to an applet, and trying to read them
raises a security exception: 

    user.name		(userid, login ID) 
    user.dir		(user's current directory)
    user.home		(user's home directory)
    java.home		(where the Java stuff is installed) 
    java.classpath	(CLASSPATH being used by that browser) 

This is described further on http://java.sun.com/sfaq/, and there
are examples that show how to read these properties.  Also there's
an example that shows what should happen when an applet tries to 
read a "hidden" property. 

For the JDK appletviewer only: a user can turn off the reading of the
ten "open" properties by modifying the client's ~/.hotjava/properties
file.  Note that NN2.x doesn't read the properties file, so changing
your properties file won't affect what happens with that browser.

Note also that JavaScript != Java. I don't know the list of properties
or environment variables that can or cannot be accessed with a
JavaScript script.

Note also that most HTTP servers will as part of their normal
operation service http requests to get the header info (that is, the
headers defined as part of HTTP 1.0) - some of that info includes
things like HTTP vendor, release, etc.

There has been a lot of net traffic about Java applets that can be
used to "spoof email."  From what I've seen, these applets simply
determine the hostname of the computer that the applet is running on,
then connect back to the server they came from, and send email from eg
root@clienthostname.  The applet can't get the user name.  My reaction
to this is that you certainly wouldn't need to go to the trouble to
run an applet in order to get a hostname -- any simple HTTP request
returns to the requestor the name of the hostname that services that
request, so these kind of attacks are not specific to Java applets.  I
haven't seen any Java applet that can succeed in getting the user
name.  We'd consider that a privacy bug that would need to get fixed
ASAP.  If anyone has a Java applet that can get the userid, file a
bug!    Email cheerfully accepted, I can turn that into a bug report
on our end. 

Marianne
JavaSoft
mrm@eng.sun.com

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