Presentation on theme: "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."— Presentation transcript:
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