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