Transcript Applet Security

Applet Security
Gunjan Vohra
What is Applet Security?
• One of the most important features of Java is its security
model. It allows untrusted code, such as applets
downloaded from arbitrary web sites, to be run in a
restricted environment that prevents that code from doing
anything malicious, like deleting files or sending fake
email.
• Applet security is implemented to protect users from
unknowingly loading a malicious program that can be
hidden on a Web page.
What Applets can do?
• Applets can usually make network
connections to the host they came from.
• Applets running within a Web browser can
easily cause HTML documents to be
displayed.
• Applets can invoke public methods of other
applets on the same page.
What Applets can do? (contd.)
• Applets that are loaded from the local file
system (from a directory in the user's
CLASSPATH) have none of the restrictions
that applets loaded over the network do.
• Although most applets stop running once you
leave their page, they don’t have to.
What Applets cannot do?
• An Applet cannot load libraries or define
native methods.
• It cannot ordinarily read or write files on the
host that’s executing it.
• It cannot make network connections except to
the host that it came from.
What Applets cannot do?
(contd.)
• It cannot start any program on the host that’s
executing it.
• It cannot read certain system properties
• Windows that an applet brings up look
different than windows that an application
brings up.
Trusted and Untrusted Applets
In Java-enabled web browsers, untrusted applets
cannot read or write files at all. By default,
downloaded applets are considered untrusted. There
are two ways for an applet to be considered trusted:
• The applet is installed on the local hard disk, in a
directory on the CLASSPATH used by the program
that you are using to run the applet.
• The applet is signed by the identity marked as trusted
in your identity database.
Local and Signed Applets
• Local Applets
When an applet is loaded from the local file system,
instead of through a network protocol, web browsers
and applet viewers may relax some, or even many, of
the restrictions mentioned in the previous slides. The
reason for this is that local applets are assumed to be
more trustworthy than anonymous applets from the
network.
Local and Signed Applets
(contd.)
• Signed Applets
Java has the ability to attach a digital signature to a
JAR file that contains an applet. This signature
securely identifies the author or origin of an applet. If
you trust the author or originating organization, you
can configure your web browser or applet viewer to
run applets bearing that signature as trusted code,
rather than as untrusted code. Such an applet runs
without the onerous security restrictions placed on
untrusted applets.
Applet Class Loader
• Applets loaded over the net are loaded by the applet
class loader. For example, the appletviewer's applet
class loader is implemented by the class
sun.applet.AppletClassLoader.
• The class loader enforces the Java name space
hierarchy. It guarantees that a unique namespace
exists for classes that come from the local file
system, and that a unique namespace exists for each
network source.
Applet Class Loader (contd.)
• Classes loaded by the class loader are
passed through the verifier. The verifier
ensures that:
– There are no stack overflows or underflows.
– All register accesses and stores are valid.
– The parameters to all byte code instructions are
correct.
– There is no illegal data conversion.
Security Manager
• When you run an applet, you bring the
classes for that applet across the wire from
the host machine so that they operate on
your local machine. The Java Applet Security
Manager sets certain limits on the byte code
that can be downloaded to the local machine
for an applet, and disallows certain behaviors
by applets to protect applet users.
Security Manager (contd.)
The Security Manager has the following duties:
• Prevent installation of new class loaders.
• Protect threads and thread groups from each other.
• Control the execution of other application programs.
• Control the ability to shut down the VM.
• Control access to other application processes.
Security Manager (contd.)
• Control access to system resources such as print
queues, clipboards, event queues, system properties,
and windows.
• Control file system operations such as read, write,
and delete. Access to local files is strictly controlled.
• Control network socket operations such as connect
and accept.
• Control access to Java packages (or groups of
classes), including access to security enforcement
classes.
Writing a Security Manager
• By default an application does not have a security
manager. That is, the Java runtime system does not
automatically create a security manager for every
Java application. So by default an application allows
all operations that are subject to security restrictions.
• To change this default lenient behavior, an application
must create and install its own security manager.
Writing a Security Manager
(contd.)
• To write your own security manager, you must create
a subclass of the SecurityManager class. Your
SecurityManager subclass overrides various methods
from SecurityManager to customize the verifications
and approvals needed in your Java application.
• Detailed instructions about writing a security manager
can be found at:
http://java.sun.com/docs/books/tutorial/essential/syst
em/writingSMgr.html
Installing the Security Manager
• Once you've completed writing your SecurityManager
subclass, you can install it as the current security
manager for your Java application. You do this with
the setSecurityManager() method from the System
class.
• The detailed instructions about installing a security
manager can be found at:
http://java.sun.com/docs/books/tutorial/essential/syst
em/installSMgr.html
Allowing an Applet to read a file
• Applets loaded into a Java-enabled browser can't
read files.
• Sun's appletviewer allows applets to read files that
are named on the access control list for reading
which is initially null by default, in the JDK
• You can allow applets to read directories or files by
naming them in the acl.read property in your
~/.hotjava/properties file.
Allowing an Applet to read a file
(contd.)
• For example, to allow any files in the directory
home/me to be read by applets loaded into the
appletviewer, add this line to your
~/.hotjava/properties file.
acl.read=/home/me
• Use ":" to separate entries:
acl.read=/home/foo:/home/me/somedir/somefile
Note: Allowing an applet to read a directory means that it can read all
the files in that directory, including any files in any subdirectories.
Allowing an Applet to write a file
• Applets loaded into a Java-enabled browser can't
write files.
• Sun's appletviewer allows applets to write files that
are named on the access control list for writing. The
access control list for writing is empty by default.
• You can allow applets to write to your /tmp directory
by setting the acl.write property in your
~/.hotjava/properties file:
Allowing an Applet to write a file
(contd.)
• For example:
acl.write=/tmp
• Use : to separate entries:
acl.write=/tmp:/home/me/somedir/somefile
Note: If you open up your file system for writing by applets, there is no
way to limit the amount of disk space an applet might use.
Areas unprotected by the
security manager
• Currently, a hostile applet can crash a user's browser
by:
– Allocating memory until it runs out.
– Firing off threads until everything slows to crawl.
• These kinds of attacks are called Denial of Service
attacks.
• The security manager does not allow you to enforce
any kind of limit on allocated memory or thread
creation.
Areas unprotected by the
security manager (contd.)
• Some other kinds of hostile applets that
currently are possible:
– Applets that send unauthorized e-mail from the user's
computer
– Applets that make annoying noises even after you
leave the Web page
– Applets that display offensive images or animations
Bibliography
• http://www.javaworld.com/javaworld/jw-12-2000/jw1215-security.html
• http://java.sun.com/docs/books/tutorial/applet/overvie
w/security.html
• http://java.sun.com/docs/books/tutorial/applet/practic
al/security.html
• http://www.unix.org.ua/orelly/java-ent/jfc/ch07_03.htm
• http://java.sun.com/developer/technicalArticles/Securi
ty/applets/index.html