/ciol/media/agency_attachments/c0E28gS06GM3VmrXNw5G.png)
Follow UsApplets are Java programs embedded in HTML pages and executed within the browser
environment. They have inherent safety features that prevent programmers from writing
malicious code. The security mechanism is good enough for the common user to surf in
peace. This article does a reality check on applet security.
Security model for applets
The applet security model is a four-pronged mechanism. A standard Java compiler will not
let illegal type conversions and pointer arithmetic pass by it. The Applet Class Loader in
the browser loads Applets imported from different network sources, and maintains separate
identities for each of them. The class loader tests the applet code with the Bytecode
Verifier to check for purposeful violations of language rules. This step is needed to make
sure that the applet was not compiled using a "hostile" non-standard compiler
specifically developed to circumvent the rules. Then the Applet Security Manager takes
over, playing watchman throughout the working of the applet.
What applets cannot do
The security manager imposes several restrictions on what applets can and cannot do. An
applet loaded from a network does not have access to the local file system, and cannot
establish a network connection to any host other than the one from which it was
downloaded. It cannot define native method calls to access system hardware directly
either.
In short, applets are prevented from passing sensitive system information to a hacker and
using another SMTP server to send forged e-mail. The security manager will blow the
whistle whenever it detects a violation, and program execution ceases. There is a catch,
though.
Trusted applets are privileged
Applets that reside on the client's local disk, and in one of the directories in the
CLASSPATH, are treated differently. These are known as trusted applets. They are not
loaded by the applet class loader, not subjected to the bytecode verifier, and not
scrutinized by the security manager. Trusted applets have full access to the local file
system, and can connect to any port of any site on the Internet.
Hostile Java applets
Most "hostile" applets found today are not those that circumvent established
security mechanisms, but which tend to be more of a nuisance: taking up system resources,
crashing browsers, making continuous noises, and the like. Just shut the browser window,
and never visit that site again.
The real hostile applets are Trojan horses -- seemingly harmless programs that work
maliciously behind the scenes. Java Trojans may be simple applets that perform attractive
tasks. It must be tempting enough for the unsuspecting user to want it on their own
homepage. The user will download and test it on a local system, where there are no
security cordons.
If the program detects that it has been loaded by the local file system rather than the
class loader, the malicious portion of the code will be fired. Since all applets can read
and write files on the server of origin, sensitive information can collected from the
local system and stored on the hacker's Web site. However, at all times, the user will see
the regular function that the applet was meant to do.
Preventing an applet attack
For a Trojan applet to carry through, it must be made trusted. Usually, the hacker will
provide instructions on how to install the applet in the CLASSPATH. Informed users know
that applets can be run from any directory. If the instructions insist on working from the
CLASSPATH, it is a tell-tale sign of mischief. In fact, an interesting experiment
conducted in 1997 demonstrated this exact sequence of getting a Trojan applet to work.
When testing applets, it is advisable to use a personal Web server. The browser will then
subject these applets to the same security restrictions as network applets.
For the record, there has been no known wide-scale applet attack due to hostile applets.
Popular anti-virus software like McAfee VirusScan detect many "nuisance"
applets, wrongly classifying them as hostile Java classes.
Security in Java 2
With JDK 1.2, also known as the Java 2 platform, the Java Security Model has been updated
with new or improved features. There are tools to generate digital signatures for JAR
files, verify the authenticity of signed content, and manage digital certificates from
trusted parties.
Once the source of an applet has been certified, it can be granted access to file and
network resources. In fact, even network applets can be given access rights if they are
certified. However, it is still up to the user to judiciously trust or reject the applet.
| Related Sites |
Details of an experiment that demonstrates the working of a Trojan applet
Java Security FAQ
Answers to questions of restrictions imposed on applets
Low Level Security in
Java
A paper on the working of low-level security including bytecode verification
| Articles in context |
Web
Linx - Java Applets
Tech Bytes - Digital
Certificates
Web Linx - Java Servlets