The Art of Software Security Testing and over one million other books are available for Amazon Kindle. Learn more

Vous voulez voir cette page en français ? Cliquez ici.

Sign in to turn on 1-Click ordering.
More Buying Choices
Have one to sell? Sell yours here
Start reading The Art of Software Security Testing on your Kindle in under a minute.

Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.

The Art of Software Security Testing: Identifying Software Security Flaws [Paperback]

Chris Wysopal , Lucas Nelson , Dino Dai Zovi , Elfriede Dustin

List Price: CDN$ 57.99
Price: CDN$ 46.39 & FREE Shipping. Details
You Save: CDN$ 11.60 (20%)
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Temporarily out of stock.
Order now and we'll deliver when available. We'll e-mail you with an estimated delivery date as soon as we have more information. Your account will only be charged when we ship the item.
Ships from and sold by Gift-wrap available.


Amazon Price New from Used from
Kindle Edition CDN $34.44  
Paperback CDN $46.39  

Book Description

Nov. 17 2006 0321304861 978-0321304865 1

Risk-based security testing, the important subject of this book, is one of seven software security touchpoints introduced in my book, Software Security: Building Security In. This book takes the basic idea several steps forward. Written by masters of software exploit, this book describes in very basic terms how security testing differs from standard software testing as practiced by QA groups everywhere. It unifies in one place ideas from Michael Howard, David Litchfield, Greg Hoglund, and me into a concise introductory package. Improve your security testing by reading this book today.”

Gary McGraw, Ph.D., CTO, Cigital; Author, Software Security, Exploiting Software, Building Secure Software, and Software Fault Injection;


“As 2006 closes out, we will see over 5,000 software vulnerabilities announced to the public. Many of these vulnerabilities were, or will be, found in enterprise applications from companies who are staffed with large, professional, QA teams. How then can it be that these flaws consistently continue to escape even well-structured diligent testing? The answer, in part, is that testing still by and large only scratches the surface when validating the presence of security flaws. Books such as this hopefully will start to bring a more thorough level of understanding to the arena of security testing and make us all a little safer over time.”

Alfred Huger, Senior Director, Development, Symantec Corporation


“Software security testing may indeed be an art, but this book provides the paint-by-numbers to perform good, solid, and appropriately destructive security testing: proof that an ounce of creative destruction is worth a pound of patching later. If understanding how software can be broken is step one in every programmers’ twelve-step program to defensible, secure, robust software, then knowledgeable security testing comprises at least steps two through six.”

Mary Ann Davidson, Chief Security Officer, Oracle


“Over the past few years, several excellent books have come out teaching developers how to write more secure software by describing common security failure patterns. However, none of these books have targeted the tester whose job it is to find the security problems before they make it out of the R&D lab and into customer hands. Into this void comes The Art of Software Security Testing: Identifying Software Security Flaws. The authors, all of whom have extensive experience in security testing, explain how to use free tools to find the problems in software, giving plenty of examples of what a software flaw looks like when it shows up in the test tool. The reader learns why security flaws are different from other types of bugs (we want to know not only that ‘the program does what it’s supposed to,’ but also that ‘the program doesn’t do that which it’s not supposed to’), and how to use the tools to find them. Examples are primarily based on C code, but some description of Java, C#, and scripting languages help for those environments. The authors cover both Windows and UNIX-based test tools, with plenty of screenshots to see what to expect. Anyone who’s doing QA testing on software should read this book, whether as a refresher for finding security problems, or as a starting point for QA people who have focused on testing functionality.”

Jeremy Epstein, WebMethods


State-of-the-Art Software Security Testing: Expert, Up to Date, and Comprehensive


The Art of Software Security Testing delivers in-depth, up-to-date, battle-tested techniques for anticipating and identifying software security problems before the “bad guys” do.


Drawing on decades of experience in application and penetration testing, this book’s authors can help you transform your approach from mere “verification” to proactive “attack.” The authors begin by systematically reviewing the design and coding vulnerabilities that can arise in software, and offering realistic guidance in avoiding them. Next, they show you ways to customize software debugging tools to test the unique aspects of any program and then analyze the results to identify exploitable vulnerabilities.


Coverage includes

  • Tips on how to think the way software attackers think to strengthen your defense strategy
  • Cost-effectively integrating security testing into your development lifecycle
  • Using threat modeling to prioritize testing based on your top areas of risk
  • Building testing labs for performing white-, grey-, and black-box software testing
  • Choosing and using the right tools for each testing project
  • Executing today’s leading attacks, from fault injection to buffer overflows
  • Determining which flaws are most likely to be exploited by real-world attackers


This book is indispensable for every technical professional responsible for software security: testers, QA specialists, security professionals, developers, and more. For IT managers and leaders, it offers a proven blueprint for implementing effective security testing or strengthening existing processes.


Foreword xiii

Preface xvii

Acknowledgments xxix

About the Authors xxxi


Part I: Introduction

Chapter 1: Case Your Own Joint: A Paradigm Shift from Traditional Software Testing  3

Chapter 2: How Vulnerabilities Get Into All Software  19

Chapter 3: The Secure Software Development Lifecycle  55

Chapter 4: Risk-Based Security Testing: Prioritizing Security Testing with Threat Modeling  73

Chapter 5: Shades of Analysis: White, Gray, and Black Box Testing  93


Part II: Performing the Attacks

Chapter 6: Generic Network Fault Injection  107

Chapter 7: Web Applications: Session Attacks  125

Chapter 8: Web Applications: Common Issues  141

Chapter 9: Web Proxies: Using WebScarab  169

Chapter 10: Implementing a Custom Fuzz Utility  185

Chapter 11: Local Fault Injection  201


Part III: Analysis

Chapter 12: Determining Exploitability  233


Index  251

Customers Who Bought This Item Also Bought

Product Details

Product Description

About the Author

Chris Wysopal is cofounder and CTO of Veracode, where he is responsible for the software security analysis capabilities of Veracode’s technology. Previously he was vice president of research and development at @stake. As a member of the groundbreaking security research think tank L0pht Heavy Industries, he and his colleagues testified to the U.S. Senate that they could “take down the Internet in 30 minutes.” They were praised as “modern-day Paul Reveres” by the senators for their research and warnings of computer security weaknesses. Wysopal has also testified to the U.S. House of Representatives and has spoken at the Defense Information Systems Agency (DISA), Black Hat, and West Point. He is coauthor of L0phtCrack, the password auditor used by more than 6,000 government, military, and corporate organizations worldwide. He earned his bachelor of science degree in computer and systems engineering from Rensselaer Polytechnic Institute in Troy, New York.


Lucas Nelson is the technical manager for Symantec’s New York region, where he is responsible for all aspects of security consulting services delivery. Within Symantec he also leads the Application Security Center of Excellence, which develops application security practices and guidelines and trains new hires in the methodology of application testing. He has taught a number of classes on both attacking and defending computer systems to several groups, including state governments and large financial institutions. Nelson worked as a developer specializing in security for a number of small startups before joining Symantec/ @stake in 2002. He researched computer security at Purdue University’s CERIAS lab under the guidance of professor Eugene Spafford, graduating with a degree in computer science.


Dino A. Dai Zovi is a principal member of Matasano Security, where he performs ShipSafe product penetration tests for software vendors and DeploySafe third-party software penetration tests for enterprise clients. He specializes in product, application, and operating system penetration testing and has done so in his previous roles at Bloomberg, @stake, and Sandia National Laboratories. He is also a frequent speaker on his computer security research, including presentations at the Black Hat Briefings, IEEE Information Assurance Workshop, Microsoft’s internal Blue Hat Security Briefings, CanSecWest, and DEFCON. He graduated with honors with a bachelor of science in computer science and a minor in mathematics from the University of New Mexico.


Elfriede Dustin is author of Effective Software Testing and lead author of Automated Software Testing and Quality Web Systems, books that have been translated into various languages and that have sold tens of thousands of copies throughout the world. The Automated Testing Lifecycle Methodology (ATLM) described in Automated Software Testing has been implemented in various companies throughout the world. Dustin has written various white papers on software testing. She teaches various testing tutorials and is a frequent speaker at software testing conferences. In support of software test efforts, Dustin has been responsible for implementing automated test and has acted as the lead consultant/manager guiding the implementation of automated and manual software testing efforts. She is cochair of VERIFY, an annual international software testing conference held in the Washington, DC area. Dustin has a bachelor of science in computer science. She has more than 15 years of IT experience and currently works as an independent consultant in the Washington, DC area. You can reach her via her Web site at


Excerpt. © Reprinted by permission. All rights reserved.

Foreword and Preface


Who can argue with testing things before you allow yourself to depend on them? No one can argue. No one will argue. Therefore, if testing is not done, the reasons have to be something other than a reasoned objection to testing. There seem to be exactly three: I can't afford it, I can get along without it, and I don't know how.

  • Not being able to afford it—Allowing for economists to disagree over fine points, the cost of anything is the foregone alternative. If you do testing, what didn't you do? If it is to add yet another feature, perhaps you deserve congratulations on choosing a simpler product. Simpler products are in fact easier to test (and for good reason: the chief enemy of security is complexity, and nothing breeds complexity like creeping featuritis). If you didn't do testing, the usual reason given is to "get the product out on time." That reason is insufficient if not petulant. The sort of testing taught in this book is about the future even more than getting the product out on time is about the future. Only CEOs intoxicated on visions of wealth are immune to thinking about the future in ways that preclude testing. Testing is about controlling your future rather than allowing it to control you. Testing accelerates the inevitable future failure of products into the present. When William Gibson famously said, "The future is already here—it's just unevenly distributed," he wasn't thinking of testing as we mean it here. What you explicitly want is to unevenly distribute the future so that your product gets to see its future before your customers (and opponents) do. Since you are reading this paragraph, it's pretty likely you are of a testing frame of mind, so we'll drop the argument and move on.
  • Getting along without it—Some products probably don't need much testing. They are not subject to innovation; they're nonperishable commodities, or something equally boring. That's not why we are here. We are here to protect security-sensitive products. Which products are those? A product is security-sensitive if, in its operation, it faces sentient opponents. If the only perils it faces are cluelessness ("Hey, watch this!") or random happenstance (alpha particles), the product may well not be security-sensitive. But with software and networks being as they are, nearly everything is security-sensitive because, if nothing else, every sociopath is your next-door neighbor. The burden of perfection is no longer on the criminal to commit the perfect crime but rather is on the defender to commit the perfect defense. Sure, you can get away with not testing, just as you can get away with never wearing protective gear while you band-saw aluminum, mountain-bike in Moab, or scrub down a P3 containment lab. There's always someone who has gotten away with that and more. That doesn't apply here. Why? Because the more successful and widespread your product is, the more those sociopaths, the more those sentient opponents, will adopt you as a special project. Just ask Microsoft. If you want to get widespread adoption, you will be tested. The only question is "Tested by whom?"
  • Not knowing how—And so we come to the purpose of this book. You are ready, willing, and unable. Or you want to make sure that you're as up to date as your opponents. Or you need raw material for even more extreme sports than what is outlined here. You've come to a right place (there is no "the" right place). This is (let's be clear) a very right place. The authors are proven, and the techniques are current. Although techniques in security have the terrible beauty of never being "done," you won't do much better than these. If you can, there is an audience for your book. In the meantime, absorb what Chris Wysopal, Lucas Nelson, Dino Dai Zovi, and Elfriede Dustin have to teach you, and put it into practice. Skill sets like these do not grow on trees, and they don't stand still any more than the opposition stands still.

As you can see from the table of contents, testing is a way of thinking, not a button to press or a budget item to approve. You very nearly have to adopt this way of thinking—and nothing enforces a way of thinking as much as the regular use of tools and techniques that embody it. This is no joke. The outside attacker is skillful and increasingly professional and has tools and thought patterns. Malware—in particular, malware that turns good citizens into unintentionally bad citizens—has made true the long-standing supposition of security geeks: The real threat is the insider.

Question: What is an external attacker's first measure of success? Answer: Gaining an insider's credentials, access, and authority. If that attacker intends to do so by exploiting software the target insider runs, only your design and your testing stand in the way of the attacker's goals. As shown in the following figure, the idea is not "Does the product do what it is supposed to do?" but "Does the product not do what it supposed to not do?" That question is far harder than the quality assurance question because it is inherently open-ended. It cannot be fully handled by development per se. It has to be tested—preferably by informed testers not tangled up with the build process.

That, again, is where this book comes in. It tells you how to exert the kind of expert pressure that does accelerated failure time testing. You learn how to do so efficiently enough to be willing to do the testing and not think that you can get away without it. In other words, this is hunting in the bush. You can learn to do it by yourself, but following an expert tracker is a faster education than learning everything the hard way. Absorb everything that is here, and you'll either be a formidable hunter or you'll be in a position to be a tracker yourself. Remember, all skill is the result of practice. These authors are well practiced; it is your turn, and they have given you a leg up.

Daniel E. Geer, Jr., Sc.D.
24 July 2006


  1. Herbert H. Thompson and James A. Whittaker. Testing for Software Security. Dr. Dobb's Journal, 27(11): 24–32, November 2002.


With the growth of threats targeting computer systems, various organizations and institutions are looking for solutions that protect brand equity and customer confidence while minimizing maintenance costs.

The challenge is growing because of the widening scope of threats. Attackers started with UNIX-based Internet services and then moved to Windows-based PCs. Now they are beginning to target Apple MacOS X systems, networked video game consoles, wireless handheld devices, and even cell phones. After a software vulnerability is exposed, it often takes less than a week for hackers to come up with an exploit for it. And although the window of vulnerability has shrunk, it still takes about six weeks before software vendors issue a security patch. 1

Symantec has reported that attackers are moving away from large, multiple-purpose attacks against traditional security devices such as firewalls and routers. At Symantec, 69% of the vulnerabilities reported in the last half of 2005 were in Web applications.

Instead, attackers are focusing their efforts on regional targets, desktops, and Web applications that potentially allow an attacker to steal corporate, personal, financial, or confidential information. A new Symantec Internet Security Threat Report cites the growing trend of attackers using bot 2 networks, targeted attacks on Web applications and Web browsers, and modular malicious code.

Security issues often translate into the loss of revenue and reputation for an organization. They also can result in the loss of market share, which may be vital to the organization's future. The security firms Counterpane Internet Security and MessageLabs estimate that a piece of malware with a modest infection rate could cost a small company $83,000 a year—and may cost a large company $1 million or more. They add that these are direct losses and do not include indirect losses such as losses of reputation. 3

Dave Cullinane, chief information security officer of the financial firm Washington Mutual in Seattle says, "If you have an application exposed to the Internet that will allow people to make money, it will be probed." Cullinane believes the consequences of being breached are not only financial but also damaging to the company's reputation. "The reputation risk can literally put you out of business. Twenty percent to 45% of customers will leave you if you report a security breach." 4 CardSystems, which processes credit card transactions, nearly went out of business because of software that let criminals steal the private financial data of millions of customers. The com-pany that purchased CardSystems was ordered by the FTC to undergo independent audits for the next 20 years.

This book discusses how this type of insecure handling of sensitive data could have been prevented. Specifically, testing for these types of scenarios is covered in Chapters 6 and 7.

Additionally, this CardSystems security disaster could possibly have been prevented if security testing had been part of the company's process and if it had learned how to detect this type of situation. Then, when it was detected, the company could have taken the removal steps discussed. Keep in mind that it is against the VISA PCI regulations to store most secrets at all. This is a credit card security standard and security policy requirement that should have...

Customer Reviews

There are no customer reviews yet on
5 star
4 star
3 star
2 star
1 star
Most Helpful Customer Reviews on (beta) 4.3 out of 5 stars  7 reviews
9 of 9 people found the following review helpful
4.0 out of 5 stars Good overview but not a one stop shop Jan. 12 2008
By Chris Gates - Published on
This is a good "short" version of "The Art of Software Security Assessment" by Dowd. For a security book its short, at 250 pages. The book contains useful information but not enough to be an expert at anything. This is definitely one of those mile wide, inch deep books and not a one stop shop as it says in the preface. It covers topics in enough detail to have heard of the issue and some of the chapters give you some links to further information but you wont come away with enough knowledge to actually do many of the attacks talked about.

It does hit the major attack vectors; Ch6 Generic Network Fault Injection, Ch7 Web Applications: Session Attacks, Ch8 Web Applications: Common Issues, Ch9 Web Proxies: Using WebScarab, Ch10 Implementing a Custom Fuzz Utility, and Ch11 Local Fault Injection. So thats a plus. The first part of the book on Secure Software Development Lifecycle was good, but again, not really enough information to be the only book you need on the subject. The third part of the book on analysis, Ch12 Determining Exploitability, was really not useful to me its way too short and tries to cram exploit development into 25 pages which just isn't possible. It shows you some diagrams of the stack and heap then some winDbg screen shots of nameless programs crashing and overwriting EIP (stack) and EAX (heap) and a null dereference. Fairly anti-climatic and doesn't dispel the "magic" of writing exploits.

Things I liked; the WebScarab chapter (Ch9) was good, that can be a tough tool to get up and running with all of its options. The Web Application chapters (Ch 7 & Ch8) are pretty good overviews. Part 1 of the book on the SSDL, overview of how vulnerabilities get into code, and risk-based security testing was useful to me and serves as a good into to the Dowd book.

Things I didn't like; Chapter 12 on Determining Exploitability was too short and not enough information, no code for the custom web application they use for examples for SQL Injection. I'm very much a "have to do it" guy and not having the code was a disappointment and lastly the book's website seems to have never been updated after first standing it up.

I'd recommend the book to people who need to get an idea of security flaws, how they get into code and some visual examples of those flaws. But only if they needed either a high level overview or they need an initiation to the topic. For people who need a deep knowledge I'd refer them to the Dowd book.
7 of 8 people found the following review helpful
5.0 out of 5 stars Great resource for software testers interested in security Feb. 8 2007
By G. Gheorghiu - Published on
"The Art of Software Security Testing" is the first security testing book I read that includes a reputable software tester (Elfriede Dustin) among its authors. This should lend the book instant credibility with its main target audience: testers and QA engineers. The security proficient readers will be happy to know that the main author is Chris Wysopal, one of the members of the famous L0pht Heavy Industries security research group who testified before the US Senate that it is possible and indeed within their power to "take down the Internet in 30 minutes".

Most security testing books adopt a black-box approach, detailing security assessment and penetration testing techniques that view the "victim" -- be it a device, an operating system or an application -- as an unknown quantity (or should I say quality, since we're talking about testing) that is probed and attacked from the outside in. A few books adopt a white-box approach, teaching code inspection and secure coding techniques, viewing the software from the inside out. "The Art of Software Security Testing" is a fortunate blend of the two approaches, teaching its readers how to conduct what is called "gray-box testing", which is of course what you get when you combine black and white.

When it comes to assessing the security of an application, testers have one important advantage over outside attackers: they can collaborate with the designers and developers of the application and get an insider view of what the book repeatedly refers to as "the attack surface", basically the list of all the inputs and resources used by the program under test. Armed with this knowledge, testers can then apply a wealth of techniques that attempt to break the security of the application, and that can be summarized in two words: fault injection. Indeed, the bulk of the book is devoted to the presentation of techniques and tools that assist testers as they try to make the application fail by feeding it various types of inputs (hence the term fault injection). These inputs range from carefully crafted strings used in SQL Injection attacks, to random byte changes in given input files, to random strings fed as command line arguments. Two important classes of fault injection tools discussed throughout the book are proxies (such as WebScarab) which allow the attacker to intercept and modify traffic to and from the application under test, and fuzzers (such as CLI Fuzz) which allow the attacker to inject random inputs into the application. As an aside, I liked the fact that the authors discuss mostly freely available Open Source tools.

If you are a tester trying to assess the security of an application, a developer trying to improve the security of your code, or even if you are a seasoned security practitioner trying to learn new ways to attack software, this book is for you. I, as a tester, found valuable advice right in Chapter 1: act as a detective by applying the fault injection model, think as an attacker, prioritize your work via threat modeling, and rely heavily on automated tools. All this and more in a fairly slim book, whose size and weight make it inappropriate for a door stop -- a use I have been tempted to give to many oversized security books.
8 of 10 people found the following review helpful
5.0 out of 5 stars Book for All Software Professionals Dec 6 2006
By J. Rashka - Published on
This book should be read by everyone in a position of responsibility for developing, testing and/or implementing a software application.

The paradigm shift in thinking outlined in The Art of Software Security Testing has been needed in the application security area for sometime. This shift includes a focus on disciplined approaches to performing security requirements definition, secure software development and responsive security testing, where the greatest vulnerabilities exist.

Instead of security C&A teams preparing documents and checking boxes, a leadership role is needed within organizations to modify application development with an emphasis on security throughout the software development lifecycle from security requirements definition through structured security testing.

Finally a book that effectively articulates the actions we all need to perform for securing applications and building secure applications. This book is written at the right technical level and provides guidance to industry and government professionals who must deliver real projects under considerable schedule pressure.

Jeff Rashka

Director of Applications

US Federal Highway Administration
3 of 4 people found the following review helpful
4.0 out of 5 stars Highly recommended primer Aug. 19 2007
By Dennis L. Hughes - Published on
Format:Paperback|Verified Purchase
This review refers to the 2007 edition of "The Art of Software Security Testing" by Wysopal, Nelson, Zovi, & Dustin.

I highly recommend this as a primer for anyone interested in software security testing.

First, it is up-to-date. In a very useful discussion the book points out that the nature of attacks and attackers have changed considerably in recent years. Methods for protecting oneself must change accordingly.

The book is brief, comprehensive, and generally well written. One finds a goodly amount of practical information to get started. More importantly, one gets a broad understand of the primary areas of interest acting as a guide for further study.

Everything is touched upon in sufficient detail for a book of this type. Part I covers the genesis of security defects, the Secure Software Development Lifecycle (SSDL), and Threat Modeling. Part II covers common types of attacks and how to test for them, including Network Fault Injection, Web Application Session Attacks, and SQL Injection. Part III covers stack and heap overflows and how to assess their exploitability.

Many of the topics covered deserve volumes of their own such as Threat Modeling (Microsoft Professional), Exploiting Software: How to Break Code (Addison-Wesley Software Security Series), and The Security Development Lifecycle. But this book will give you lay of the land and enough knowledge to get started on security testing right away.

The book misses 5 stars because it becomes difficult to follow in places. The book attempts to cover both Windows and UNIX/Linux systems, and occasionally confuses the two, at least in the mind of the reader. One example is the section on "Port Discovery" where the authors discuss similar and completely different UNIX and Windows tools in a confusing interleaved fashion. It would have been wiser to separate the discussion of Windows and UNIX systems into discrete sections.

That said, I highly recommend the book as a primer on security testing for it's coverage, brevity, and up-to-date information.
5 of 7 people found the following review helpful
4.0 out of 5 stars how to design and test to remove weaknesses Nov. 30 2006
By W Boudville - Published on
If you are considering this book, you should also look at another book published around the same time - "The Art of Software Security Assessment" by Dowd et al. The latter is a much heftier tome, of some 1100 pages. While the current book is a relatively slender 260 pages or so. Both cover essentially the same subject, explaining the Secure Software Development Cycle and its ramifications.

But Wysopal et al offer a more concise rendition, that can be easily covered in a day or so, by someone already in the programming field. Major attack techniques are explained. SQL injection, buffer overruns, cross site scripting, man in the middle proxies etc. Enough sample code is provided for each to show the technical reader how the attack is done. Naturally, the book also devotes space to countermeasures. How to design and write preventive code. Or, stated another way, how not to write code that is susceptible to those attacks. Also, the utility of various testing modes (black, white, grey) is emphasised. You have to assume a different mindset; that of the attacker. A little troubling to some readers, perhaps. But vital to catch weaknesses in your code as early as possible. Preferably before it has shipped to customers.

As an aside: On page 13, it imagines a Web application with 10 forms with 10 fields in each. Where each field can take an input of 100 alphanumeric characters. So each field has a total of 62^100 combinations. The text says the total number of combinations for the application is 10 x 10 x 62^100. No. It is actually much, much larger. 62^(100*100).

If you find this book germane to your situation, and want more technical details, then try consulting the Dowd book.

Look for similar items by category