Introduction
Since JAVA was introduced to the world of web in 1995, it has dominated the web software market in a few years. From the beginning, it designed as a simple, object-oriented, distributed, interpreted, robust, secure, architecture neutral, portable, high-performance, multi-threaded, and dynamic language. Though it has devised well as a secure language, it also has some secure holes. This document touches the JAVA's secure model, security attacks and antidotes, and their related links.
- What Applets Can't Do
- Read files on the client file system.
- Write file stop the client file system.
- Delete files on the client file system.
- Rename files on the client file system.
- Create a directory on the client file system.
- List the contents of a directory.
- Check to see whether a file exists.
- Obtain information about a file.
- Create a network connection to any computer other than the host from which it originated.
- Listen for or accept network connections on any port on the client system.
- Create a top-level window without an untrusted window banner any means including trying to read the system properties.
- Define any system properties.
- Run any program on the client system.
- Make the Java interpreter exit.
- Load dynamic libraries on the client system.
- Create or manipulate any thread that is not part of the same ThreadGroup as the applet.
- Create a ClassLoader.
- Create a SecurityManger.
- Specify any network control functions.
- Define classes that are part of packages on the client system.
- Three-Pronged Defense
Java Security Model
Java introduced several security protection models to prevent from potential attacks. To get this protection, it does not allow some functions through network loading and had three-pronged defense structure.
