ITS 4050 - Internet and Web Security

Chapter 8, Mitigating Web Application Vulnerabilities

This lesson presents some material from chapter 8. Objectives important to this lesson:

1. Causes
2. Policies
3. Secure coding: HTML, JavaScript, CGI forms, and database access
4. Software management
   

Concepts:

Chapter 8

The chapter begins with a familiar list of problems:

• servers must send forms/pages for user input
• an application server must process the user requests after validating them
  
• the application must interact with the database needed for the request
• authentication must be secure so it can be trusted
• sessions must be managed to avoid tampering or hijacking
  

The text begins some new material on page 213, discussing code in applications that breaks their security. The next three pages describe twenty five types of coding errors that can cause major problems. Several can be grouped together by the categories in the bullet list above. It is a bad practice, for example, to have a hard coded credential in a program, although it makes testing faster. That kind of back door is a great prize for a hacker. Thirty years ago, I did not see a danger in leaving that troubleshooting option in a program. I no longer feel that way.

On page 216, the text begins its section on mediation methods. It begins with policies, by which it means business rules. Page 217 offers a list of eight elements that are common to a unified security policy:

• Data security to be used in storage (at rest) and in transit (in motion). The text does not mention "in processing", which is often considered to be a third possibility.
• Asset inventory policies concern the process to issue equipment to employees and to receive it back from them under each of several circumstances.
• End-user security may mean the precautions we expect every end-user to observe. It may also include security policies to protect the organization from the end-users.
• Physical security issues have been discussed already. The policies of the organization should be formalized for easy access and understanding.
  
• Access control mechanisms have been discussed as well. As noted, policies should be made available to staff who need to know.
• Incident management and reporting policies need to be understood by staff who deal with incidents, by staff who report incidents, and by anyone experiencing an incident.
• Fault-tolerance measures should have policies as well, so that each new system can meet requirements, and so existing systems can be brought up to current standards when they are regularly reviewed.
  

In addition to these elements, the text provides some questions to ask yourself, to make sure you are on the right track when writing, reviewing, or updating security policies:

• What are we protecting? Understanding your asset inventory helps to focus on whether a policy has value for one or more of them.
• What are the threats and vulnerabilities of the assets in question? Is the policy going to be effective for them?
• What are the mitigation strategies? What are we going to do about it?
• What is the review schedule for the policy? Not only a calendar schedule, but an event schedule as well. What may happen that should cause us to review this or another policy?

The advice about mitigating problems begins on page 220 and continues to the end of the chapter. Each of the sections talks about the same issues, but from the perspective of a developer using a compiled language, HTML, a scripting language, forms, and database access. It also discusses conducting application reviews, which means examining all of the other discussed features. These are some of the highlights from this section:

• Validate and sanitize input
• Watch for warnings when compiling and testing, and resolve them
• Be aware of security policies, and write your application to be compliant
• Write simple code. It's easier to troubleshoot, update, and change. Be kind to those who inherit your work.
• Use minimal access and least privilege
• Use layers of security
• Encrypt data traffic
• Check scripts and HTML pages regularly to find hacks
• Log error messages, but don't show them all to users because hackers can use them
• Harden systems, and have your applications work within the hardening