Tải bản đầy đủ - 0trang
development lifecycle. Different organizations react differently to the need for security,
however, and no two organizations are the same.
We are not going to tell you much about why you should include security testing in
your testing methodology. There are ample books trying to address that question. We
can’t cover what it means to your organization if you have poor security in your software
or how you perform a risk analysis to determine your exposure to software-induced
business risk. Those are important concepts, but they’re beyond the scope of this book.
How, Not What
We are not going to provide you with a database of test data. For example, we will tell
you how you can test for SQL injection or cross-site scripting, but we won’t provide a
comprehensive set of malicious inputs that you can use. There are plenty of resources
for that sort of thing online and we’ll refer you to a few. Given the rapidly changing
nature of software security, you’re better off getting up-to-the-minute attack data online, anyway. The techniques presented in these recipes, however, will last a long time
and will be helpful in delivering attacks of many kinds.
How, Not Where
This book does not present a methodology for assessing your application looking for
weak spots. Assessing a web application—once or on a continuing basis—is not what
we’re helping you do. Assessors come in and find problems. They do not bring the
deep, internal knowledge of the application that the QA staff and developers have.
External consultants do not fit into the software development lifecycle and apply tests
at the unit, integration, and system level. If you need an overall methodology on how
to assess a web application from the ground up, there are many good books on how to
do that. When it’s time to do some of the tasks mentioned in those books, though,
you’ll discover that many are laid out in good detail within the recipes in this book.
How, Not Who
Every organization will have to decide who will perform security testing. It might be
(and probably should be) a combination of both developers and testers. It can involve
folks from the IT security side of the house, too, but don’t let them own security testing
completely. They don’t understand software and software development. If security
testing falls exclusively to the testing and quality side of the organization, then you will
want someone with some software development skills. Although we are not developing
a software product here, the scripts and test cases will be easier to use and reuse if you
have experience with programming and scripting. Even operations staff might benefit
from the recipes in this book.
How you decide whom to assign to these tasks, how you organize their work, and how
you manage the security testing is beyond the scope of this book.
1.5 It’s About the How | 15
How, Not When
Integrating security testing, like any other kind of specialized testing (performance,
fault tolerance, etc.), requires some accommodations in your development lifecycle.
There will be additional smoke tests, unit tests, regression tests, and so on. Ideally these
tests are mapped back to security requirements, which is yet one more place your lifecycle needs to change a little. We are going to give you the building blocks to make
good security tests, but we won’t answer questions about what part of your test cycle
or development methodology to put those tests into. It is difficult to develop security
test cases when security requirements are not specified, but that is a topic for another
book. Instead, we are going to help you build the infrastructure for the test cases. You
will have to determine (by experimenting or by changing your methodology) where
you want to insert them into your lifecycle.
Software Security, Not IT Security
If you play word association games with IT people and say “security,” they’ll often
respond with “firewall.” While firewalls and other network perimeter protections play
an important role in overall security, they are not the subject of this book. We are talking
about software—source code, business logic—written by you, operated by you, or at
least tested by you. We don’t really consider the role of firewalls, routers, or IT security
software like antivirus, antispam, email security products, and so on.
The tests you build using the recipes in this book will help you find flaws in the source
code itself—flaws in how it executes its business functions. This is handy when you
need to check the security of a web application but you do not have the source code
for it (e.g., a third-party application). The techniques are especially powerful when you
have the source itself. Creating narrow, well-defined security tests allows you to facilitate root cause analysis right down to the lines of code that cause the problem.
Although there are products that call themselves “application firewalls” and claim to
defend your application by interposing between your users and youro application, we
will ignore such products and such claims. Our assumption is that the business logic
must be right and that it is our job—as developers, quality assurance personnel, and
software testers—to systematically assess and report on that correctness.
16 | Chapter 1: Introduction
Installing Some Free Tools
Every contrivance of man, every tool, every instrument,
every utensil, every article designed for use, of each and
every kind, evolved from a very simple beginning.
These tools can cover the breadth and depth needed to perform comprehensive web
application security testing. Many of these tools will be useful to you, yet some not.
The usefulness of any individual tool will depend heavily on your context—particularly
the web application’s language and what you most need to protect.
This chapter is a reference chapter, even more so than the rest of the book. These recipes
recommend tools and discuss a bit of their use and background. Unlike later chapters,
these recipes don’t directly build up to comprehensive security tests.
Instead, this chapter can be thought of as part of setting up your environment. Just as
you might set up a separate environment for performance testing, you’ll want to set up
at least one workstation with the tools you’ll need for security testing. That said, many
people use the regular QA server and environment for security tests—and this generally
works well. Just beware that any security test failures may corrupt data or take down
the server, impacting existing test efforts.
2.1 Installing Firefox
The Firefox web browser, with its extensible add-on architecture, serves as the best
browser for web application security testing.
Using your system default web browser, visit http://www.mozilla.com/en-US/firefox/.
Figure 2-1. Approving the View Source Chart extension
Based on your User-Agent string (see Recipe 5.7 for details on User-Agents), the Firefox
website will identify your operating system. Click the Download button, and install
Firefox the same way you would any application. Make sure you have sufficient machine privileges!
Even if your application isn’t specifically written for Firefox compatibility, you can use
Firefox to test the less aesthetic, behind the scenes, security-focused aspects. In the case
where using Firefox breaks functionality outright, you will need to rely on web proxies,
command-line utilities, and other browser-agnostic tools.
2.2 Installing Firefox Extensions
Firefox extensions provide a great deal of additional functionality. We recommend a
few particular extensions for web application security testing. All of these extensions
are installed in a similar fashion.
Using Firefox, browse to the extension page (listed below).
Click the Install Extension button to add this extension to Firefox, and approve the
installation of the extension when prompted, as shown in Figure 2-1.
18 | Chapter 2: Installing Some Free Tools