Security

When designing an applet, you must be aware of the things that an applet is not allowed to do. Generally, applets are not allowed to:
  • Read from or write to files on the local machine.
  • Delete or rename files on the local machine.
  • Create a directory on the local machine.
  • List directory contents.
  • Check for the existence of a file.
  • Start, called forking a process, any program on your system, i.e. applets cannot call any of the Runtime.exec() functions.
  • Create a network connection to any computer other than the one from which the applet was loaded.
  • Obtain the user's username or home directory name.

    • Further:

  • Java's memory allocation model is one of its main defenses against malicious code (e.g can't cast integers to pointers, so can't forge access).
  • access restrictions are enforced (public, private).
  • byte code is verified, which copes with the threat of a hostile compiler.

    • Byte code verification also checks that the code:

  • is valid Java Virtual Machine code
  • does not over- or underflow the stack
  • does not use registers incorrectly
  • does not convert data types illegally

    • For more questions and concerns about Java security, check out Java security FAQ.

    Even with all these restrictions, there are still a lot of "hostile" applets out there. These are applets that allocate lots of memory, run many threads, or download lots of data. In other words, applets that test your patience!

    Even worse are the applets that cause Netscape to hang. These and other malicious applets can be found at: Hostile applets.

    The following link points to a page that describes security bugs in Sun Microsystem's Java development kit, and Java enabled browsers such as Netscape: Security bugs in java.

    Back to Lecture3