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

More documents

Recommendations

Info

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
GUIDELINES ON SECURING PUBLIC WEB SERVERS The areas of vulnerability mentioned potentially affect all Web servers. Although these vulnerabilities have frequently occurred with CGI applications, other related interfaces and techniques for developing server applications have not been immune. CGI, being an early and well-supported standard, has simply gained more attention over the years, and the same areas of vulnerability exist when applying similar Web development technologies. CGI scripts were the initial mechanism used to make Web sites interact with databases and other applications. However, as the Web evolved, server-side processing methods have been developed that are more efficient and easier to program; for example, Microsoft provides ASP.NET for its IIS servers, Sun/Netscape supports Java servlets, and the freeware PHP is supported by most major Web platforms, including Apache and IIS [<strong>NIST</strong>01]. Some important points to consider when contemplating the deployment of CGI [Ziri02]: The host file system (see Section 4.1) provides security for CGI. Most servers allow per-directory CGI restrictions. CGI itself provides little security enforcement. Perl facilitates secure programming that most other languages (e.g., C, C++, sh) do not. CGI wrappers available from third parties offer additional protection for CGI. Server Side Includes (SSI) is a limited server-side scripting language supported by most Web servers. SSI provides a set of dynamic features, including the current time or the last modification date of the HTML file, as an alternative to using a CGI program to perform the function. When the browser requests a document with a special file type, such as “.shtml”, it triggers the server to treat the document as a template, reading and parsing the entire document before sending the results back to the client (Web browser). SSI commands are embedded within HTML comments (e.g., ). As the server reads the template file, it searches for HTML comments containing embedded SSI commands. When it finds one, the server replaces that part of the original HTML text with the output of the command. For example, the SSI command given above (i.e., #include file) replaces the entire SSI comment with the contents of another HTML file. This allows the display of a corporate logo or other static information prepared in another file to occur in a uniform way across all corporate Web pages. A subset of the directives available allows the server to execute arbitrary system commands and CGI scripts, which may produce unwanted side effects [<strong>NIST</strong>01]. Some important points to consider when contemplating the deployment of SSIs: The security of SSIs is extremely weak if the exec command is enabled on the Web server. The impact of SSIs can hurt the performance of heavily loaded Web servers. The security of SSIs relies heavily on the host OS and Web server application for security. Microsoft ASP.NET is a server-side scripting technology from Microsoft that can be used to create dynamic and interactive Web applications. An ASP page contains server-side scripts that run when a browser requests an “.asp” resource from the Web server. The Web server processes the requested page and executes any script commands encountered before sending a generated HTML page to the user’s browser. Both C# and VBScript are natively supported as ASP.NET scripting languages, but other languages can be accommodated, if an ASP.NET-compliant interpreter for the language is installed. For example, ASP.NET engines are available for the Perl, REXX, and Python languages from various 6-13
Page 1 and 2:
Special Publication 800</st
Page 3 and 4:
GUIDELINES ON SECURING PUBLIC WEB S
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14: GUIDELINES ON SECURING PUBLIC WEB S
Page 63: GUIDELINES ON SECURING PUBLIC WEB S
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
show all

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?