To get around this security restriction, all you need to do is edit your local Domain Name Service (DNS) resolver configuration. For most Unix and Windows systems, this is often done by editing your local HOSTS file:
Simply map the "machine_name" where the applet came from to some arbitrary Internet address. That is, add a line like the following to your HOSTS file: "www.machine_name.com 1.2.3.4." Then restart your Navigator browser, and you'll find that now you can use applets from www.machine_name.com.
As stated above, with Navigator, when a firewall/proxy server is present and the internal network does not provide external DNS resolution users cannot access the Java applet-based site at java.sun.com:81. The typical circumstance involves a user not having the capability to do external DNS resolution. Most (if not all) companies do NOT provide external DNS resolution. Simply by adding the line "1.2.3.4 java.sun.com" to their HOSTS file, users can now fully access java.sun.com:81.
I believe the reason adding a line to the HOSTS file gives users access to the site is because of a small security glitch in how the applet security manager checks to see what IP address the applet came from. In the example above, the site of origin is java.sun.com, which maps to an IP address of 1.2.3.4 on my machine. Then when the applet wants to connect back to java.sun.com for whatever reason, the applet security manager again checks to see what IP address the applet wants to connect back to. Once again, java.sun.com will map to 1.2.3.4. The applet security manager then compares the identical 1.2.3.4 responses and allows the connection to be made.
Note: This security glitch requires some explanation and some understanding of Java applet security. If you look at what's on http://home.att.net/wisniewski/DNSSpoofing.html, you will find an overview of the issues involved as well as links to the original sites that described DNS Spoofing concerns.
The security glitch occurs at the point that this second applet request is made: What is supposed to happen based on any secondary applet request is that the URL request should be rewritten from http://java.sun.com/whatever to http://1.2.3.4/whatever before the request gets passed from the applet to the browser and then to the firewall/proxy server. But the URL request does not get rewritten. The applet requests keeps the URL request as http://java.sun.com, which forces the proxy to do another DNS resolution.
very interestingBy Anonymous on September 7, 2009, 1:57 pmI hope people don't fix the issue, its a welcome glitch
Reply | Read entire comment
Nice ArticleBy Anonymous on April 29, 2009, 7:00 amIts really an orsom article. Cheers!!! Ujjwal B Soni Baroda, Gujarat, India
Reply | Read entire comment
View all comments