"If popular culture has taught us anything, it is that someday mankind must
face and destroy the growing robot menace."
- Daniel H. Wilson,
How to Survive a Robot Uprising
The past several years have seen huge strides in computer security, particularly
in the field of software vulnerabilities. It seems as though every stop at the
bookstore introduces a new title on topics such as secure development or exploiting
software.
Books that cover application security tend to do so from the perspective of
software designers and developers and focus on techniques to prevent software
vulnerabilities from occurring in applications. These techniques start with
solid security design principles and threat modeling and carry all the way through
to implementation best practices and defensive programming strategies. Although
they serve as strong defensive foundations for application development, these
resources tend to give little treatment to the nature of vulnerabilities; instead,
they focus on how to avoid them. What's more, every development team can't start
rebuilding a secure application from the ground up. Real people have to deal
with huge existing codebases, in-place applications, and limited time and budget.
Meanwhile, the secure coding mantra seems to be "If it smells bad, throw
it out." That's certainly necessary in some cases, but often it's too expensive
and time consuming to be reasonable. So you might turn your attention to penetration
testing and ethical hacking instead. A wide range of information on this topic
is available, and it's certainly useful for the acid test of a software system.
However, even the most technically detailed resources have a strong focus on
exploit development and little to no treatment on how to find vulnerabilities
in the first place. This still leaves the hanging question of how to find issues
in an existing application and how to get a reasonable degree of assurance that
a piece of software is safe.
This problem is exactly the one faced by those in the field of professional
software security assessment. People are growing more concerned with building
and testing secure systems, but very few resources address the practice of finding
vulnerabilities. After all, this process requires a deep technical understanding
of some very complex issues and must include a systematic approach to analyzing
an application. Without formally addressing how to find vulnerabilities, the
software security industry has no way of establishing the quality of a software
security assessment or training the next generation in the craft. We have written
this book in the hope of answering these questions and to help bridge the gap
between secure software development and practical post-implementation reviews.
Although this book is aimed primarily at consultants and other security professionals,
much of the material will have value to the rest of the IT community as well.
Developers can gain insight into the subtleties and nuances of how languages
and operating systems work and how those features can introduce vulnerabilities
into an application that otherwise appears secure. Quality assurance (QA) personnel
can use some of the guidelines in this book to ensure the integrity of in-house
software and cut down on the likelihood of their applications being stung by
a major vulnerability. Administrators can find helpful guidelines for evaluating
the security impact of applications on their networks and use this knowledge
to make better decisions about future deployments. Finally, hobbyists who are
simply interested in learning more about how to assess applications will find
this book an invaluable resource (we hope!) for getting started in application
security review or advancing their current skill sets.
Prerequisites
The majority of this book has been targeted at a level that any moderately experienced
developer should find approachable. This means you need to be fairly comfortable
with at least one programming language, and ideally, you should be familiar
with basic C/C++ programming. At several stages throughout the book, we use
Intel assembly examples, but we have attempted to keep them to a minimum and
translate them into approximate C code when possible. We have also put a lot
of effort into making the material as platform neutral as possible, although
we do cover platform specifics for the most common operating systems. When necessary,
we have tried to include references to additional resources that provide background
for material that can't be covered adequately in this book.
How to Use This Book
Before we discuss the use of this book, we need to introduce its basic structure.
The book is divided into three different parts:
- Part I: Introduction to Software Security Assessment (Chapters 1–4)—These
chapters introduce the practice of code auditing and explain how it fits into
the software development process. You learn about the function of design review,
threat modeling, and operational review—tools that are useful for evaluating
an application as a whole, and not just the code. Finally, you learn some
generic high-level methods for performing a code review on any application,
regardless of its function or size.
- Part II: Software Vulnerabilities (Chapters 5–13)—These chapters
shift the focus of the book toward practical implementation review and address
how to find specific vulnerabilities in an application's codebase. Major software
vulnerability classes are described, and you learn how to discover high-risk
security flaws in an application. Numerous real-world examples of security
vulnerabilities are given to help you get a feel for what software bugs look
like in real code.
- Part III: Software Vulnerabilities in Practice (Chapters 14–18)—The
final portion of the book turns your attention toward practical uses of lessons
learned from the earlier chapters. These chapters describe a number of common
application classes and the types of bugs they tend to be vulnerable to. They
also show you how to apply the technical knowledge gained from Part II to
real-world applications. Specifically, you look at networking, firewalling
technologies, and Web technologies. Each chapter in this section introduces
the common frameworks and designs of each application class and identifies
where flaws typically occur.
You'll get the most value if you read this book straight through at least once
so that you can get a feel for the material. This approach is best because we
have tried to use each section as an opportunity to highlight techniques and
tools that help you in performing application assessments. In particular, you
should pay attention to the sidebars and notes we use to sum up the more important
concepts in a section.
Of course, busy schedules and impending deadlines can have a serious impact
on your time. To that end, we want to lay out a few tracks of focus for different
types of reviews. However, you should start with Part 1 (Chapters 1–4)
because it establishes a foundation for the rest of the book. After that, you
can branch out to the following chapters:
- UNIX track (Chapters 5–10, 13)—This chapter track starts off by
covering common software vulnerability classes, such as memory corruption,
program control flow, and specially formatted data.
