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

GUIDELINES ON SECURING PUBLIC WEB SERVERS
Unlike the Java sandbox model, which restricts the permissions of applets to a set of safe actions,
ActiveX places no restrictions on what a control can do. Instead, ActiveX controls are digitally signed by
their authors under a technology scheme called Authenticode. The digital signatures are verified using
identity certificates issued by a trusted certificate authority to an ActiveX software publisher, who must
pledge that no harmful code will be knowingly distributed under this scheme. The Authenticode process
ensures that ActiveX controls cannot be distributed anonymously and that tampering with the controls can
be detected. This certification process, however, does not ensure that a control will be well behaved
[<strong>NIST</strong>01]. Vulnerabilities in key ActiveX controls have been reported, including components installed by
popular applications such as Microsoft Office.
6.4.2 Vulnerabilities with Server-Side Content Generation Technologies
Unlike the above technologies, CGI, ASP .NET, Java EE, and other similar server interfaces fall on the
server side (Web) of the client-server model. Common uses of server-side execution include [Ziri02]—
Database access
E-commerce/e-government applications
Chat rooms
Threaded discussion groups.
The server-side applications can be written in many programming languages to run on a Web server. If
scripts and components are not prepared carefully, however, attackers can find and exercise flaws in the
code to penetrate the Web server or backend components such as a database server. Therefore, scripts
must be written with security in mind; for example, they should not run arbitrary commands on a system
or launch insecure programs. An attacker can find flaws through trial and error and does not necessarily
need the source code for the script to uncover vulnerabilities [<strong>NIST</strong>01].
Server-side content generators can create the following security vulnerabilities at the server:
They may intentionally or unintentionally leak information about the Web server application and host
OS that can aid an attacker, for example, by allowing access to information outside the areas
designated for Web use.
When processing user-provided input, such as the contents of a form, URL parameters, or a search
query, they may be vulnerable to attacks whereby the user tricks the application into executing
arbitrary commands supplied in the input stream (e.g., cross-site scripting or SQL injection).
They may allow attackers to deface or modify site content.
Ideally, server-side applications should constrain users to a small set of well-defined functionality and
validate the size and values of input parameters so that an attacker cannot overrun memory boundaries or
piggyback arbitrary commands for execution. Applications should be run only with minimal privileges
(i.e., non-administrator) to avoid compromising the entire Web site. However, potential security holes
can be exploited, even when applications run with low privilege settings, so this option should only be
used as a last resort. For example, a subverted script could have enough privileges to mail out the system
password file, examine the network information maps, or launch a login to a high numbered port.
6-12