During and after the design and production phases of site development, I recommend documenting the following to guide the client, programmers, and web authors after the project launches. All the hard work getting the site launched will deteriorate over time without clear guidelines.

A web site is helpful to track much of the information, but it is often private and requires security. A paper copy is recommended as well.

Topics for documentation

• Server configuration
  • Domain names and account information
  • Host accounts
    • Site
    • Ecommerce
    • Web services
  • Email accounts
  • Server software, including languages, applications, and databases
• Log of features added, to which pages, by whom, when, and how long it took.
  • Helps the bidding process if similar components are needed.
• Style Guide which illustrates
  • Graphical user interface and theme/schemes
    • color scheme
    • tag styles
    • attribute styles
    • media styles
    • table styles
    • menu styles
    • IDs and Classes
  • Scripts and functions
    • Describe each’s purpose, location, and cite the author for future bug reporting or improvements.
  • Presentation of logos, icons, images, movies, sound, and other media
  • Use of language, grammar, and special spellings.
• List of users and their roles
• Statistics
• Marketing/Advertising
  • Print requirements with examples
  • Online requirements with examples
  • Campaigns (such as Adwords or banner ads)
    • In progress
    • Completed, with a summary of the outcome
  • Link Exchanges
  • Associate/Affiliation accounts
• Training documents
  • How to login to the CMS
  • How to edit content
  • How to edit functions
  • FTP access
  • Definition of users’ roles.
• Feedback from staff and customers:
  • Formal surveys
  • User Testing
  • Focus groups
  • Informal polls
  • Individual inquiries

Readings

Web Applications Security Tutorial

Jerry Berkman, 2003.

A Guide to Building Secure Web Applications and Web Services

Open Web Application Security Project. 2005 PDF.
Open Web Application Security Project

OWASP.org. Top 10 Vulnerabilities in Web Applications. November 2006.

Secrets and Lies: Digital Security in a Networked World

Bruce Schneier, John Wiley & Sons, 2000.
ISBN 0-471-25311-1

Understanding Malicious Content Mitigation for Web Developer

(CERT 2000)

SANS Top-20 2007 Security Risks

2007 Annual Update

Web Security

W3Schools.org. An introduction.

Web Security

By Geoff Marshall. SC magazine. Account required to read the white papers.

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
  • View your computer’s vulnerabilities with ShieldsUP!
    • The Internet’s quickest, most popular, reliable and trusted, free Internet security checkup and information service. Check your system here, and begin learning about using the Internet safely.
• 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.

Write a sound security policy.

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

Readings

USA Copyright Office

FAQ

250 HTML and Web Design Secrets

Molly E Holzschlag. Wiley Publishing. 2004.

Pages 108 to 109.

To avoid academic dishonesty, breach of copyright laws, and to provide credit where credit it due, I require that students cite the sources of the following kinds of materials used in your deliverables:

• All visual material such as photos, illustrations, and icons
  • Cite the author/owner, copyright date, and URL in the alternative text tag (alt=”") or in a caption.
• Scripts such as JavaScript, .php, dhtml, etc.
  • Cite the programmer/owner, copyright date, and URL in the code or footer of your site/page.