Java Reference
In-Depth Information
choice between using a hostname such as www.oreilly.com or an IP address such as
208.201.239.37, always choose the hostname. Use an IP address only when a hostname
is not available.
Security issues
Creating a new InetAddress object from a hostname is considered a potentially insecure
operation because it requires a DNS lookup. An untrusted applet under the control of
the default security manager will only be allowed to get the IP address of the host it
came from (its codebase ) and possibly the local host. Untrusted code is not allowed to
create an InetAddress object from any other hostname. This is true whether the code
uses the InetAddress.getByName() method, the InetAddress.getAllByName() meth‐
od, the InetAddress.getLocalHost() method, or something else. Untrusted code can
construct an InetAddress object from the string form of the IP address, though it will
not perform DNS lookups for such addresses.
Untrusted code is not allowed to perform arbitrary DNS lookups for third-party hosts
because of the prohibition against making network connections to hosts other than the
codebase. Arbitrary DNS lookups would open a covert channel by which a program
could talk to third-party hosts. For instance, suppose an applet downloaded from
www.bigisp.com wants to send the message “macfaq.dialup.cloud9.net is vulnerable” to
crackersinc.com . All it has to do is request DNS information for macfaq.dial‐
up.cloud9.net.is.vulnerable.crackersinc.com . To resolve that hostname, the applet would
contact the local DNS server. The local DNS server would contact the DNS server at
crackersinc.com . Even though these hosts don't exist, the cracker can inspect the DNS
error log for crackersinc.com to retrieve the message. This scheme could be considerably
more sophisticated with compression, error correction, encryption, custom DNS
servers that email the messages to a fourth site, and more, but this version is good enough
for a proof of concept. Arbitrary DNS lookups are prohibited because arbitrary DNS
lookups leak information.
Untrusted code is allowed to call InetAddress.getLocalHost() . However, in such an
environment, getLocalHost() always returns a hostname of localhost/127.0.0.1 . The
reason for prohibiting the applet from finding out the true hostname and address is that
the computer on which the applet is running may be deliberately hidden behind a fire‐
wall. In this case, an applet should not be a channel for information the web server
doesn't already have.
Like all security checks, prohibitions against DNS resolutions can be relaxed for trusted
code. The specific SecurityManager method used to test whether a host can be resolved
is checkConnect() :
public void checkConnect ( String hostname , int port )
When the port argument is -1, this method checks whether DNS may be invoked to
resolve the specified host . (If the port argument is greater than -1, this method checks
Search WWH ::




Custom Search