A Java Applet has, by default, many restrictions. It cannot:
- open a socket connection to a server that is different from the web server that hosts the applet
- access the user’s local filesystem
- read certain system properties (e.g. user.home, java.home, …)
The reason for this is because an applet is started automatically by the web browser, not on the user’s own initiative, and therefore the user cannot take responsibility for the application’s behavior on their machine. By default the applet is called an untrusted applet (not started by the user’s own initiative), unsigned applet (the applet has not been signed by a certificate), sandbox applet (running in java’s security sandbox).
In order to eliminate these restrictions, it is possible to sign the applet using a certificate. There are two types of signed applets:
- self-signed applets: signed by the developers themselves
- signed applets: containing a signature that the browser should verify through a remotely running, independent certificate authority server (e.g. Thawte, Symantec, GoDaddy, …)
The applet is then called signed applet (the applet has been signed by a certificate). When the browser starts a signed applet, the applet will automatically request permission to run outside the security sandbox. And if the user grants permission, the applet becomes a trusted applet (the user takes responsibility), and can also be called a privileged applet (running outside the security sandbox).
Since the Java 6 Update 10 release (2008-10-15), unsigned applets can now make network connections to remote servers (servers that are different from the server that hosts the applet) using a special XML file called crossdomain.xml file. That file must be accessible on the server that the applet is trying to connect to.
Security warning dialog boxes
Since Java 7 Update 11 release (2013-01-13), the user is now always warned and asked permission to run unsigned applets (before that release, a warning dialog would only appear for signed applets). The user is prompted by a warning dialog that requires him to check a checkbox only if he accepts the risks posed by running the applet.
Also, since Java Update 21 release (2013-04-16), the warning dialog stresses furthermore (in red and bold) that running the application may be a security risk. Oracle now states on its website “Starting with Java SE 7 Update 21 in April 2013 all Java Applets and Web Start Applications are encouraged to be signed with a trusted certificate. […] self-signing is primarily of value to developer and intranet applications as it also requires managing the keystore for Java”.
Note that the dialog above also warns you that your Java is insecure if you don’t have the latest update of Java. An additional button labelled “Update” is then added to dialog forwarding the user to Oracle’s Java Download page.
Note that the option that allows the user to avoid showing the warning dialog again, is hidden until you click on “Show Options”.
Oracle, because of their recent security concerns, is dissuading the end users from running an unsigned or self-signed applet by making these warning dialogs “scarier” over the releases and by increasing the default Java security level.
From now on all your applets should be signed by a trusted SSL provider.
Don’t hesitate to comment for any updates that I might miss!
Further reading: http://threatpost.com/javas-losing-security-legacy