NIST 800-44 Version 2 Guidelines on Securing Public Web Servers

GUIDELINES ON SECURING PUBLIC WEB SERVERS
6.4.1 Vulnerabilities with Client-Side Active Content Technologies
Each active content technology has its own strengths and weaknesses; none is perfectly secure. Some of
the more popular active content technologies and their associated risks are discussed below. New
technologies are emerging all the time and older technologies are continually enhanced. Any Web
administrator or Webmaster who is considering deploying a Web site with features that require active
content technology on the client side should carefully weigh the risks and benefits of the technology
before implementation. The relative risk of active content technologies changes over time, complicating
this task. Nevertheless, common risks to the Web server prevail with all active content technologies.
Because these technologies involve placing application code on the client, an attacker may attempt to
reverse engineer the code to gain an understanding of how it functions with an organization’s Web site
and exploit that relationship. For example, relying only on input validation checks performed at the client
by the active content and not validating the input again at the Web server would allow an attacker to use
an HTTP proxy tool or editor to modify the active content elements and bypass any or all checks
performed.
Java is a full-featured, object-oriented programming language compiled into platform-independent byte
code executed by an interpreter called the Java Virtual Machine (JVM). The resulting byte code can be
executed where compiled or transferred to another Java-enabled platform (e.g., conveyed via an HTML
Web page as an applet). Java is useful for adding functionality to Web sites. Many services offered by
various popular Web sites require the user to have a Java-enabled browser. When the Web browser sees
references to Java code, the browser loads the code and processes it using the built-in JVM or a userinstalled
one.
The Java programming language and runtime environment enforce security primarily through strong type
safety, by which a program can perform certain operations only on certain kinds of objects. Java follows
a so-called sandbox security model, used to isolate memory and method access and to maintain mutually
exclusive execution domains. Java code, such as a Web applet, is confined to a “sandbox,” which is
designed to prevent it from performing unauthorized operations, such as inspecting or changing files on a
client file system and using network connections to circumvent file protections or users’ expectations of
privacy. Java byte code downloaded to the client can be decompiled into a more readable form by the
user, making it susceptible to reverse engineering and possible modification, which poses a threat to the
Web server.
Hostile applets can also pose security threats to the client, even while executing within the sandbox. A
hostile applet can consume or exploit system resources inappropriately, or can cause a user to perform an
undesired or unwanted action. Examples of hostile applet exploits include DoS, mail forging, invasion of
privacy (e.g., exporting of identity, e-mail address, and platform information), and installing backdoors to
the system. Because the Java security model is rather complex, it can be difficult for a user to understand
and manage. This situation can increase risk. Moreover, many implementation bugs have also been
found, enabling security mechanisms to be bypassed [<strong>NIST</strong>01].
JavaScript is a general purpose, cross-platform scripting language, whose code can be embedded within
standard Web pages to create interactive documents. The name JavaScript is a misnomer because the
language has little relationship to Java technology and was developed independently from it. Within the
context of the Web browser, JavaScript is extremely powerful, allowing prepared scripts to perform
essentially the same actions as those a user could take. Within that context, JavaScript lacks methods for
directly accessing a client file system or for directly opening connections to computers other than the host
that provided the content source. The browser also normally confines a script’s execution to the page
from which it was downloaded [<strong>NIST</strong>01].
6-10