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:
- Software management
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
- the application must interact with the database needed for the
- 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
- 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
- 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
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
- 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
- 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
- Be aware of security policies, and write your application to
- 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