Socket connection to originating server of an unsi

问题:

I have read everywhere that unsigned Java applets are not allowed to make network connections to any server but the one which originated the applet. This is OK for my application since my applet only needs to talk to the server. However, when I wrote a test applet to try opening a socket to communicate with a process on my development machine, it throws the following exception:

Error establishing socket connection:
java.security.AccessControlException: 
  access denied (java.net.SocketPermission 127.0.0.1:11000 connect,resolve)

The code which caused the exception:

private void sendMsg(String msg) {
   Socket s = null;
   try {
      s = new Socket("localhost", 11000);
   }
   catch (Exception e) {
      System.err.println("Error establishing socket connection:");
      e.printStackTrace();
      return;
   }

   try {
      OutputStream out = s.getOutputStream();
      out.write(msg.getBytes());
      out.flush();
      s.shutdownOutput();
      s.close();
   }
   catch (Exception e) {
      System.err.println("Error in writing to the socket:");
      e.printStackTrace();
   }

At first I thought it was a problem in my code that my inexperience had caused me to miss. However, I get the same exception when trying to run the Talk Server example from the official Java Tutorials. This leads me to believe that I actually have a setup problem, or a misunderstanding of the default security restrictions. Does the default security manager prevent you from opening sockets to the machine running the applet even if it is also the machine serving the applet? If so, that is a problem for me because the deployed system will need to allow a user logged in on the actual server to use the same applet that a remote user would use. Is there a way around the exception I'm getting that doesn't involve signing the applet? I don't want to go to the trouble if not necessary.

NOTE: I know it would be better not to have users access the applet from the server. That wasn't the original design, but practical considerations unfortunately forced this implementation compromise on me.

UPDATE: Viewing the applet's page from a webserver solves the problem. Even if the server is localhost. The security update in Java 1.6.0_11 only applies to applets loaded directly from the local file system.

回答1:

This is due to a change in the PlugIn introduced in a recent security update. Sorry! Applets loaded from the local file system are no longer granted socket permissions to localhost.

Solution 246387 : A Security Vulnerability in the Java Runtime Environment may Allow Code Loaded From the Local Filesystem to Access LocalHost

The Java Runtime Environment (JRE) allows code loaded from the local filesystem to access localhost. This may allow code that is maliciously placed on the local filesystem and then subsequently run, to have network access to localhost that would not otherwise be allowed if the code were loaded from a remote host. This may be leveraged to steal cookies and hijack sessions (for domains that map a name to the localhost).

回答2:

I suspect you're running the applet from a local HTML file (eg applet.html), which brings up the error Tom Hawtin mentions.

Instead run a webserver (eg Tomcat) on your machine and access the file through http://localhost/applet.html

It would be probably be better to open the socket port from a servlet in your webserver too. This way your webserver manages your whole system, and it can be simpler to transfer between machines.

I use the same setup regularly with socket connection between applet and servlet on both localhost and live.

回答3:

Oracle knows of this Java problem that severely restricts use of Applets: A Security Vulnerability in the Java Runtime Environment may Allow Code Loaded From the Local Filesystem to Access LocalHost is what they're saying. This was Bug Id 6704154

And their solution is: There is no workaround for this issue; this 'workaround' was issued 03-Dec-2008. So, if you wish to use Applets with Tomcat or any like server, you'll have to go back to Java 1.4.2

It took me over a week to fully document these facts and since I'm in the same boat.