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

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS as usernames and passwords or hidden server resources in URIs is not recommended. Security through obscurity is not secure. URIs are often included with public Web content. Although these URIs may not display as Web content in a user’s Web browser, they can be easily discovered in the source code. Therefore, no publicly served Web content should include sensitive URIs hidden in the source code. Many attackers and malicious bots (see Section 5.2.4) search the source code for sensitive URI information, including— E-mail addresses Images on other servers Links to other servers Particular text expressions (e.g., userid, password, root, administrator) Hidden form values Hyperlinks. A cookie is a small piece of information that may be written to the user’s hard drive when the user visits a Web site. The intent of cookies is to allow servers to recognize a specific browser (user). In essence, they add state to the stateless HTTP protocol. Because cookies are usually sent in the clear and stored in the clear on the user’s host, they are vulnerable to compromise. There are known vulnerabilities in certain versions of Internet Explorer, for example, that allow a malicious Web site to remotely collect all of a visitor’s cookies without the visitor’s knowledge. Therefore, cookies should never contain data that can be used directly by an attacker (e.g., username, password). OMB M-00-13 27 explicitly states that Federal Web sites should not use cookies unless there is a compelling need to gather the data on the site, and only with the appropriate approvals, notifications, and safeguards in place. For Web sites that need to maintain session information, the session identifier can be passed as part of the URL to the Web site rather than stored as a cookie. Regardless of whether cookies are being used or not, SSL/TLS should be used to prevent attackers from retrieving information from the HTTP messages sent over the network and using it to hijack a user’s session. 5.2.4 Controlling Impact of Web “Bots” on Web Servers Web bots (also known as crawlers or spiders) are software applications used to collect, analyze, and index Web content. Web bots are used by numerous organizations for many purposes. Some examples include— MSNBot, Slurp, and Googlebot slowly and carefully analyze, index, and record Web sites for Web search engines such as Windows Live Search, Yahoo! and Google. Mediabot is used by Google to analyze content served by an AdSense page so that contextually relevant ads will be supplied. Hyperlink “validators” are used by Webmasters to automatically validate the hyperlinks on their Web site. 27 OMB M-00-13, Office of Management and Budget Memorandum 2000-13, 2000, is available at http://www.whitehouse.gov/omb/memoranda/m00-13.html. 5-6
GUIDELINES ON SECURING PUBLIC WEB SERVERS EmailSiphon and Cherry Picker are bots specifically designed to crawl Web sites for electronic mail (e-mail) addresses to add to spam mailing lists. These are common examples of bots that may have a negative impact on a Web site or its users. Many spambots crawl Web sites for login forms to create free e-mail addresses from which to send spam or to spam blogs, guestbooks, wikis, and forums to boost the search engine rankings of a particular Web site. Screen scrapers retrieve content from Web sites to put up a copy on another server. These copies can be used for phishing or for attempting to generate ad revenue by having users visit the copy. Some malicious bots crawl Web sites looking for vulnerable applications containing sensitive data (e.g., Social Security Numbers [SSN], credit card data). Bots can present a challenge to Webmasters’ administration of their servers because— Web servers often contain directories that do not need to be indexed. Organizations might not want part of their site appearing in search engines. Web servers often contain temporary pages that should not be indexed. Organizations operating the Web server are paying for bandwidth and want to exclude robots and spiders that do not benefit their goals. Bots are not always well written or well intentioned and can hit a Web site with extremely rapid requests, causing a reduction in responsiveness or outright DoS for legitimate users. Bots may uncover information that the Webmaster would prefer remained secret or at least unadvertised (e.g., e-mail addresses). Fortunately, Web administrators or the Webmaster can influence the behavior of most bots on their Web site. A series of agreements called the Robots Exclusion Protocol (REP) has been created. Although REP is not an official Internet standard, it is supported by most well-written and well-intentioned bots, including those used by most major search engines. Web administrators who wish to limit bots’ actions on their Web server need to create a plain text file named “robots.txt.” The file must always have this name, and it must reside in the Web server’s root document directory. In addition, only one file is allowed per Web site. Note that the robots.txt file is a standard that is voluntarily supported by bot programmers, so malicious bots (such as EmailSiphon and Cherry Picker) often ignore this file. 28 The robots.txt file is a simple text file that contains some keywords and file specifications. Each line of the file is either blank or consists of a single keyword and its related information. The keywords are used to tell robots which portions of a Web site are excluded. 28 Other methods for controlling malicious bots exist; however, they are changing constantly as the malicious bot operators and Web administrators develop new methods of counteracting each other’s techniques. Given the constantly changing nature of this area, discussion of these techniques is beyond the scope of this document. More information is available at http://www.onguardonline.gov/spam.html. 5-7
Page 1 and 2: Special Publication 800</st
Page 3 and 4: GUIDELINES ON SECURING PUBLIC WEB S
Page 47: GUIDELINES ON SECURING PUBLIC WEB S
Page 99 and 100:
GUIDELINES ON SECURING PUBLIC WEB S
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
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

Create successful ePaper yourself

Delete template?

Save as template?