Web Security Checklist

Posted in Policies and Security and User Data 3 years, 3 months ago at 11:24 am

Web site security is a full time job because your web site is public for every hour of every day.

“The heart of the issue is that if untrusted content can be introduced into a dynamic page, neither the server nor the client has enough information to recognize that this has happened and take protective actions.”

Understanding Malicious Content Mitigation for Web Developer (CERT 2000)

Use this checklist to lesson the impact of malicious activity in cyberspace:

Assess the risks (Gin, 2008)

• Identify protected resources such as web pages, databases, employee information, and credit card data.
• Assign relative values to each to identify which are priorities to protect with your time and tools.
• Identify possible attackers such as hackers, ex-employees, spies, or government agencies.
• Estimate the relative frequency of attackers.

Code with security in mind.

1. Assess the risks of using scripts and forms.
2. Stay abreast of security vulnerabilities via CERT
3. Set the character encoding (meta tag) to ISO
   • < meta http-equiv=”Content-Type” content=”text/html; charset=IOS-8859-1″ >
4. Put code/scripts in a separate directory outside the document root. (Berkman 2003)
   • But do not put general purpose interpreters, such as perl, PHP, or shells, in the cgi-bin directory.
   • Store database account name and password in a file outside the web directory tree.
5. Recode dynamically generated pages to validate output.
   • Code sites so they work with or without JavaScript.
     • Because JavaScripts can introduce insecurities, some uses keep it turned off in their browsers. Tools like NoScript make it easy to turn it on when viewing a trusted site.
   • “Any server that creates web pages by inserting dynamic data into a template should check to make sure that the data to be inserted does not contain any special characters (e.g., “<”). If the inserted data contains special characters, the user’s web browser will mistake them for HTML markup.” (CERT 2000)
6. Validate form data and disallow html and scripts in form fields.
   • Limit field data to what is needed and no more. For instance, if you ask for a person’s age in a form field, only accept numbers with 2 digits rather than any amount of any characters. In a name field, accept only a string of letters, periods, and hyphens. Apostrophes may allow SQL injections.
   • Validate/filter form data locally (during the output process) before it is rendered as part of the dynamic page.
   • If you validate form data with JavaScript, revalidate with your server script (in case JavaScript was turned off in the browser).
   • Don’t allow html tags in form textarea or input fields.
   • Add Captcha Image security functions to keep spambots from filling in your forms.
7. Examine and filter data stored in cookies.
   • It is a good practice to save the session data on the server, and use cookies or hidden variables just to pass a session identifier. (Berkman 2003)
   • Cookie data can be stolen by other web pages so don’t store sensitive data in them.
8. Don’t send scripts or personal form data via link tags.
   • Malicious HTML Tags Embedded in Client Web Requests: CERT® Advisory 2000
   • Send forms with method=”post” rather than method=”get” as much as possible.
     (Berkman 2003)
     • With POST the form input is passed via standard input to the application; best for logged in sessions.
     • With GET the form input is added to the URL which is visible to users; so don’t use this option for sending personal data.
   • Don’t pass important information via hidden variables. For instance, a BuyNow button that shows pricing in a hidden field can easily be copied, altered, and sent back so a purchase is made with the wrong pricing! Read Shopping-cart glitch could give hackers a discount: Ann Harison CNN.com 2000.
9. Require users to create strong passwords.
   • And display errors to login/authentication that do not give away missing information.
   • To prevent another user from using the back button to relog in as the previous user, create a random key for each login page, save it on the server and pass it to the browser in a hidden variable, and only allow the random key to be used once to log on. (Berkman 2003)
   • Limit the number of failed login attempts.
   • Prohibit shared accounts.
   • Don’t use generic account names like tester, guest, sysadmin, admin, etc.
10. Don’t list script errors on web pages that are launched.
    • They give away the vulnerabilities of the scripts.
11. For PHP Scripts
    • Upgrade to PHP 5.2 to eliminate common vulnerabilities. some of these include:
      • PHP Remote File Include
      • SQL Injection where a CGI inserts input data into a string which is then submitted to an SQL server. See a quick example from Berkman.
      • Cross-Site Scripting (XSS) where the attacker tricks the victim into clicking on a URL containing a harmful script.
      • Cross-site request forgeries (CSRF)
    • Consider using methods like SUPHP to set permissions to read only.
      • This method can use an .htaccess file to handle permissions for complex database-driven web applications.
      • Read more: Secure PHP Pages with SUPHP: University of Virginia.
      • PHP’s security functions can all be turned on but most open source web applications cannot run with them on.
    • Remove all .phps or php.txt files from the server.
    • Remove automatically generated directory listings.
    • Create directories outside the server tree for session and sensitive data.
12. For SQL databases, read Sans.org’s Top 20 List.
13. Don’t list email addresses in web pages.
    • Use forms instead.

Test your scripts for vulnerabilities

1. Many
   older scripts, free downloadable scripts, and samples scripts from textbooks do not adhere to security best practices, so test your site to see which scripts need attention. Try these tools:
   • OWASP Testing Guide
   • Top 10 Web Vulnerability Scanners
2. Removed vulnerable scripts from the server. W3.org provides a list of problem CGI scripts.
3. Measure your skill using the GSSP or other security exams and fill commit to regularly learning new security skills.

Create strong passwords

• Perfect Passwords: GRC’s Ultra High Security Password Generator
• Password Dos and Don’ts: Bytes Interactive

Manage passwords securely

1. Read about Password Management Best Practices: MTech. 2008. And Password Management vs. Single Sign-On.
2. Management options include:

• • Desktop software
  • Browser extension
  • Hosted online service
  • Single Sign On (SSO)

Host your web site with a reliable company that provides the following services:

1. Secure server room with limited access to staff and outsiders.
2. Secure credit card transaction when purchasing the account.
   • Is the transaction as safe if handled manually by a human?
3. Strong password generation for accounts.
4. Daily backup of files and databases.
5. Immediate technical support to troubleshoot security issues.
6. Investment in finding the culprit (reporting to police)

If using e-commerce then read

• Encrypt transmission of cardholder data
  and sensitive information across public networks
• Maintain a Vulnerability Management
  Program
• Use and regularly update anti-virus
  software
• Develop and maintain secure systems and
  applications
• Implement Strong Access Control
  Measures
• Restrict access to data by business need-to-
  know
• Assign a unique ID to each person with computer access
• Restrict physical access to cardholder data

Regularly Monitor and Test Networks Track and monitor all access to network resources and cardholder data

Regularly test security systems and processes

Maintain an Information Security Policy Maintain a policy that addresses information security

If you’ve built your own server, use the Robots Exclusion to protect specific directories.

• Robotstxt.org: Helping promote the Robot Exclusion Standard.
• Disable web servers that are not in use because unused, unpatched web servers contributed greatly to spread of Code Red.

Transfer files with a secure connection

• Encrypted WiFi connection
• Secure FTP (SFTP) or Secure Shell
• Logout when idle.

Use a Secure Socket Layer (SSL) Certificate when setting up online transactions.

• SSL encrypts sessions between the browser and web server.
• Generating a self-signed SSL certificate
  • Rather than purchase a “trusted” certificate, generate your own. It’s secure, but may not be trusted by your visitors.

Browse and view media files with security features turned on.

• Securing Your Web Browser:
  Will Dormann and Jason Rafail 2008.
• Example of a browser insecurity
  • Mozilla browsers fail to properly handle images: Vulnerability Note VU#879056. The United States Computer Emergency Readiness Team (US-CERT) is a partnership between the Department of Homeland Security and the public and private sectors. Established in 2003 to protect the nation’s Internet infrastructure, US-CERT coordinates defense against and responses to cyber attacks across the nation.
• Cookies: “It’s important to be aware of your cookie settings because cookies can allow sites to track your navigation during your visit to those sites.” Google

Write a sound security policy.

Read and use How to Construct Your Privacy Policy:
Direct Marketing Association.