Applet Security - Njit


2 Νοε 2013 (πριν από 4 χρόνια και 8 μήνες)

241 εμφανίσεις

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

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

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?

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

Local and Signed Applets

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

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

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

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

Writing a Security Manager

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:

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

The detailed instructions about installing a security
manager can be found at:

Allowing an Applet to read a file

Applets loaded into a Java
enabled browser can't
read files.


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

property in your


Allowing an Applet to read a file

For example, to allow any files in the directory
home/me to be read by applets loaded into the
, add this line to your


Use "
" to separate entries:

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.


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

property in your


Allowing an Applet to write a file

For example:



to separate entries:


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

Allocating memory until it runs out.

Firing off threads until everything slows to crawl.

These kinds of attacks are called
Denial of Service


The security manager does not allow you to enforce
any kind of limit on allocated memory or thread

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

Applets that make annoying noises even after you
leave the Web page

Applets that display offensive images or animations