|
|
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:
- Causes
- Policies
- Secure coding: HTML, JavaScript, CGI forms, and database access
- 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
|
