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

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS trick the user through social engineering into clicking on the maliciously crafted URL. If the user’s Web browser was vulnerable to the exploit, the user’s machine could be compromised. Since this attack does require some level social engineering, it is considered somewhat less dangerous than attacks on persistent vulnerabilities. The solution to XSS attacks is to validate all user input and remove any unexpected or potentially risky data. Another solution is to use an HTML-quoted version 45 of any user input that is presented back to other users. This will prevent the Web browsers of other users from interpreting that input and acting on any embedded commands present. 6.5 Checklist for Securing Web Content Completed Action Ensure that none of the following types of information are available on or through a public Web server Classified records Internal personnel rules and procedures Sensitive or proprietary information Personal information about an organization’s personnel Telephone numbers, e-mail addresses, or general listings of staff unless necessary to fulfill organizational requirements Schedules of organizational principals or their exact location (whether on or off the premises) Information on the composition, preparation, or optimal use of hazardous materials or toxins Sensitive information relating to homeland security Investigative records Financial records (beyond those already publicly available) Medical records Organization’s physical and information security procedures Information about organization’s network and information system infrastructure Information that specifies or implies physical security vulnerabilities Plans, maps, diagrams, aerial photographs, and architectural plans of organizational building, properties, or installations Copyrighted material without the written permission of the owner Privacy or security policies that indicate the types of security measures in place to the degree that they may be useful to an attacker Establish an organizational-wide documented formal policy and process for approving public Web content that— Identifies information that should be published on the Web Identifies target audience Identifies possible negative ramifications of publishing the information Identifies who should be responsible for creating, publishing, and maintaining this particular information 45 More information on HTML quoting is available at http://www.w3.org/TR/html4/charset.html#entities and http://www.w3.org/TR/html4/sgml/entities.html. 6-18
GUIDELINES ON SECURING PUBLIC WEB SERVERS Completed Action Provides guidelines on styles and formats appropriate for Web publishing Provides for appropriate review of the information for sensitivity and distribution/release controls (including the sensitivity of the information in aggregate) Determines the appropriate access and security controls Provides guidance on the information contained within the source code of the Web content Maintain Web user privacy Maintain a published privacy policy Prohibit the collection of personally identifying data without the explicit permission of the user and collect only the data that is absolutely needed Prohibit the use of “persistent” cookies Use the session cookie only if it is clearly identified in published privacy policy Mitigate indirect attacks on content Ensure users of the site are aware of the dangers of phishing and pharming attacks and how to avoid them Validate official communication by personalizing emails and providing unique identifying (but not confidential) information only the organization and user should know Use digital signatures on e-mail if appropriate Perform content validation within the Web application to prevent more sophisticated phishing attacks (e.g., cross-site scripting based attacks) Personalize Web content to aid in users’ identifying fraudulent Web sites Use token-based or mutual authentication if applicable Suggest the use of Web browsers or browser toolbars with phishing/ pharming protection Use current versions of DNS software with the latest security patches Install server-side DNS protection mechanisms Monitor organizational domains and similar domains Simplify the structure of organization domain names Use secure connections for logins If necessary, engage a vendor to provide stronger anti-phishing/ anti-pharming measures Client-side active content security considerations Weigh the risks and benefits of client-side active content Take no actions without the express permission of user When possible, only use widely-adopted active content such as JavaScript, PDF, and Flash When possible, provide alternatives (e.g., HTML provided along with PDF) Maintain server-side active content security Only simple, easy-to-understand code should be used Limited or no reading or writing to the file system should be permitted Limited or no interaction with other programs (e.g., sendmail) should be permitted There should be no requirement to run with suid privileges on Unix or Linux Explicit path names should be used (i.e., does not rely on path variable) 6-19
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:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20: GUIDELINES ON SECURING PUBLIC WEB S
Page 69: GUIDELINES ON SECURING PUBLIC WEB S
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?