old security checklist

Assess the risks.

Before developing interactions on a web server, determine which activities will create security risks and plan ahead to avoid being hacked:

  • 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.

Transfer files with a secure connection

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

Browse and view media files with security features turned on.

  • Securing Your Web Browser:
    Will Dormann and Jason Rafail 2008.
  • Ten Ways to Improve the Security of a New Computer (Kent and Steiner)
  • 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.”

    • Transfer files with a secure connection

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

    Browse and view media files with security features turned on.

    • Securing Your Web Browser:
      Will Dormann and Jason Rafail 2008.
    • Ten Ways to Improve the Security of a New Computer (Kent and Steiner)
    • 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.”
      1. Determine which character encoding is most secure and current. UTF-8 and ISO-8859-1 are the most common.
      2. Put code/scripts in a separate directory outside the document root.
        • 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.
          • Is moving wp-config outside the web root really beneficial?
      3. 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)
      4. 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.
      5. 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. (Apache)
        • Cookie data can be stolen by other web pages so don’t store sensitive data in them.
      6. 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.
          (W3 Schools)

          • 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!
      7. Don’t list script errors on web pages that are launched.
        • They give away the vulnerabilities of the scripts.
      8. For PHP Scripts
        • Upgrade to PHP 5.4 to eliminate common vulnerabilities.
        • 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 many 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.
      9. For SQL databases, read Sans.org’s Top 20 List.
      10. Don’t list email addresses in web pages (Naves 2011).
        • Use forms instead.
        • Email addresses are siphoned off by hackers and used to create spam mail, phishing, and spoofing, denial of service attacks, impersonate you, hack into servers, etc.
      1. Determine which character encoding is most secure and current. UTF-8 and ISO-8859-1 are the most common.
      2. Put code/scripts in a separate directory outside the document root.
        • 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.
          • Is moving wp-config outside the web root really beneficial?
      3. 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)
      4. 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.
      5. 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. (Apache)
        • Cookie data can be stolen by other web pages so don’t store sensitive data in them.
      6. 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.
          (W3 Schools)

          • 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!
      7. Don’t list script errors on web pages that are launched.
        • They give away the vulnerabilities of the scripts.
      8. For PHP Scripts
        • Upgrade to PHP 5.4 to eliminate common vulnerabilities.
        • 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 many 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.
      9. For SQL databases, Sans.org’s Top 20 List.
      10. Don’t list email addresses in web pages (Naves 2011).
        • Use forms instead.
        • Email addresses are siphoned off by hackers and used to create spam mail, phishing, and spoofing, denial of service attacks, impersonate you, hack into servers, etc.

Published by

Pam Van Londen

OSU Computer Science Instructor