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

GUIDELINES ON SECURING PUBLIC WEB SERVERS
6.4.4
Location of Server-Side Content Generators
The location of active content on the Web server is critical. If located in an incorrect directory or in a
directory with the wrong permissions, it can quickly lead to the compromise of the Web server. To avoid
this problem—
Writable files should be identified and placed in separate folders. No script files should exist in
writable folders. As an example, guest book data is usually saved in simple text files. These files
need write permissions for guests to be able to submit their comments.
Executable files (e.g., CGI, .EXE, .CMD, and PL) should be placed in separate folders. No other
readable or writable documents should be placed in these folders.
Script files (e.g., ASP, PHP, and PL) should have separate folders. It may also be beneficial to store
the scripts in a folder with a non-obvious name (e.g., not “Scripts”) to make it more difficult for an
attacker to find the scripts through direct browsing.
Include files (e.g., INC, SHTML, SHTM, and ASP) created for code reusability should be placed in
separate directories. SSI should not generally be used on public Web servers. ASP include files
should have an .asp extension instead of .inc. Note that much of the risk with include files is in their
execute capability. If the execute capability is disabled, this risk is drastically reduced.
6.4.5
Cross-Site Scripting Vulnerabilities
Cross-site scripting (XSS) is a vulnerability typically found in interactive Web applications that allows
code injection by malicious Web users into the Web pages viewed by other users. It generally occurs in
Web pages that do not do the appropriate bounds checking on data input by users. An exploited cross-site
scripting vulnerability can be used by attackers to compromise other users’ computers or to receive data
from another user’s Web session (e.g., user ID and password or session cookie). Thus, although this is a
client side exploit, it also impacts the server indirectly since a compromised user, particularly one with
elevated privileges, represents a threat to the server. XSS vulnerabilities are used frequently to conduct
phishing attacks or exploit Web browser vulnerabilities to gain control of end user PCs.
XSS vulnerabilities are highly varied and frequently unique to a particular Web application. They
encompass two general categories:
Persistent XSS vulnerabilities allow for the more powerful attacks. This vulnerability occurs when
data provided to a Web application by an untrusted user is stored persistently on the server and
displayed to other users as Web content but is not validated or encoded using HTML. A common
example of this is online message boards, wikis, and blogs where users are allowed to post HTMLformatted
messages for other users to view. In this example, after a malicious user posts a malicious
message or reply, any other user who accesses a page displaying that data and whose browser is
vulnerable to the exploit can be compromised.
Non-persistent XSS vulnerabilities, sometimes called reflected, are more common and somewhat
less dangerous than persistent vulnerabilities. Non-persistent vulnerabilities occur when data
provided by a Web client is used immediately by server-side scripts to generate a results page for that
user (e.g., login screen, search results page). If the unvalidated client-supplied data is included in the
returned page without any HTML encoding, this will allow client-side code to be injected into the
dynamic page. This might not appear to be a problem on the surface, since an attacker can only
exploit himself or herself. However, an attacker could send a specially crafted URL to a user and
6-17