Summary

Keep bugs to a minimum and track them down when they occur.

Author Biography

Chris Wysopal is CTO of Veracode Lucas Nelson is the technical manager for Symantec's New York region

Foreword	p. xiii
Preface	p. xvii
Acknowledgments	p. xxix
About the Authors	p. xxxi
Introduction	p. 2
Case Your Own Joint: A Paradigm Shift from Traditional Software Testing	p. 3
Security Testing Versus Traditional Software Testing	p. 5
SQL Injection Attack Pattern	p. 7
The Paradigm Shift of Security Testing	p. 8
High-Level Security Testing Strategies	p. 9
The Fault Injection Model of Testing: Testers as Detectives	p. 9
Think Like an Attacker	p. 11
Prioritizing Your Work	p. 13
Take the Easy Road: Using Tools to Aid in the Detective Work	p. 14
Learn from the Vulnerability Tree of Knowledge	p. 15
Testing Recipe: Summary	p. 16
Endnotes	p. 17
How Vulnerabilities Get into All Software	p. 19
Design Versus Implementation Vulnerabilities	p. 20
Common Secure Design Issues	p. 22
Poor Use of Cryptography	p. 22
Tracking Users and Their Permissions	p. 24
Flawed Input Validation	p. 25
Weak Structural Security	p. 26
Other Design Flaws	p. 28
Programming Language Implementation Issues	p. 29
Compiled Language: C/C++	p. 30
Interpreted Languages: Shell Scripting and PHP	p. 38
Virtual Machine Languages: Java and C#	p. 42
Platform Implementation Issues	p. 44
Problem: Symbolic Linking	p. 44
Problem: Directory Traversal	p. 45
Problem: Character Conversions	p. 46
Generic Application Security Implementation Issues	p. 47
SQL Injection	p. 47
Cross-Site Scripting	p. 48
Problems During the Development Process	p. 49
Poorly Documented Security Requirements and Assumptions	p. 49
Poor Communication and Documentation	p. 50
Lack of Security Processes During the Development Process	p. 50
Weak Deployment	p. 51
Vulnerability Root Cause Taxonomy	p. 52
Summary: Testing Notes	p. 53
Endnotes	p. 53
The Secure Software Development Lifecycle	p. 55
Fitting Security Testing into the Software Development Lifecycle	p. 56
Security Guidelines, Rules, and Regulations	p. 59
Security Requirements: Attack Use Cases	p. 60
Sample Security Requirements	p. 62
Architectural and Design Reviews/Threat Modeling	p. 63
Secure Coding Guidelines	p. 64
Black/Gray/White Box Testing	p. 65
Determining Exploitability	p. 65
Deploying Applications Securely	p. 66
Patch Management: Managing Vulnerabilities	p. 66
Roles and Responsibilities	p. 67
SSDL Relationship to System Development Lifecycle	p. 68
Summary	p. 70
Endnotes	p. 71
Risk-Based Security Testing: Prioritizing Security Testing with Threat Modeling	p. 73
Information Gathering	p. 74
Meeting with the Architects	p. 74
Runtime Inspection	p. 75
Windows Platform	p. 76
UNIX Footprinting	p. 80
Finalizing Information Gathering	p. 82
The Modeling Process	p. 83
Identifying Threat Paths	p. 83
Identifying Threats	p. 87
Identifying Vulnerabilities	p. 88
Ranking the Risk Associated with a Vulnerability	p. 89
Determining Exploitability	p. 90
Endnote	p. 91
Shades of Analysis: White, Gray, and Black Box Testing	p. 93
White Box Testing	p. 93
Black Box Testing	p. 94
Gray Box Testing	p. 95
Setting Up a Lab for Testing	p. 96
Fuzzers	p. 97
Sniffers	p. 97
Debuggers	p. 98
Hardware	p. 98
Commercial Testing Appliances	p. 98
Network Hardware	p. 99
Staging Application Attacks	p. 99
Lab Environment	p. 99
Network Attacks	p. 101
Endnote	p. 104
Performing the Attacks
Generic Network Fault Injection	p. 107
Networks	p. 107
Port Discovery	p. 108
netstat and Local Tools	p. 108
Port Scanning	p. 112
Proxies	p. 113
The Simplest Proxy: Random TCP/UDP Fault Injector	p. 114
Building the Fault Injection Data Set	p. 118
Man-in-the-Middle Proxies	p. 121
Conclusion	p. 122
Summary	p. 123
Endnotes	p. 123
Web Applications: Session Attacks	p. 125
Targeting the Application	p. 125
Authentication Versus Authorization	p. 126
Brute-Forcing Session and Resource IDs	p. 127
Cookie Gathering	p. 131
Determining SID Strength: Phase Space Analysis	p. 133
Cross-Site Scripting	p. 136
Conclusion	p. 139
Summary	p. 139
Endnote	p. 139
Web Applications: Common Issues	p. 141
Bypassing Authorization	p. 142
SQL Injection	p. 144
The Basics	p. 144
Database Schema Discovery	p. 149
Executing Commands on the SQL Server	p. 154
Uploading Executable Content (ASP/PHP/bat)	p. 157
File Enumeration	p. 159
Source Code Disclosure Vulnerabilities	p. 162
Hidden Fields in HTTP	p. 164
Conclusion	p. 167
Summary	p. 168
Endnotes	p. 168
Web Proxies: Using WebScarab	p. 169
WebScarab Proxy	p. 169
Conclusion	p. 182
Summary	p. 182
Endnotes	p. 183
Implementing a Custom Fuzz Utility	p. 185
Protocol Discovery	p. 185
SOAP and the WSDL	p. 189
The SOAPpy Library	p. 190
Conclusion	p. 199
Summary	p. 199
Endnotes	p. 199
Local Fault Injection	p. 201
Local Resources and Interprocess Communication	p. 201
Windows NT Objects	p. 202
UNIX set-user-id Processes and Interprocess Communication	p. 205
Threat-Modeling Local Applications	p. 206
Enumerating Windows Application Resources	p. 207
Enumerating UNIX Application Resources	p. 207
Testing Scriptable ActiveX Object Interfaces	p. 209
Identifying "Safe" Scriptable Objects	p. 211
Testing Object Interfaces	p. 213
Manual Interface Testing	p. 213
Automated ActiveX Interface Testing	p. 215
Evaluating Crashes	p. 216
Fuzzing File Formats	p. 216
File Corruption Testing	p. 217
Automated File Corruption	p. 218
Command-Line Utility Fuzzing	p. 219
Immunity ShareFuzz	p. 219
Brute-Force Binary Tester	p. 221
CLI Fuzz	p. 221
Shared Memory	p. 225
Summary	p. 228
Endnotes	p. 228
Analysis
Determining Exploitability	p. 233
Classifying a Vulnerability	p. 233
Time	p. 234
Reliability/Reproducibility	p. 234
Access	p. 235
Positioning	p. 236
Memory Trespass and Arbitrary Code Execution	p. 237
Computer Architecture	p. 238
The Stack	p. 240
Stack Buffer Overflows	p. 240
The Heap	p. 241
Determining Exploitability	p. 244
Process Crash Dumps	p. 244
Controlled Memory and Registers	p. 245
Mitigating Factors: Stack and Heap Protections	p. 249
Further Resources	p. 250
Index	p. 251
Table of Contents provided by Ingram. All Rights Reserved.

Supplemental Materials

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

Excerpts

Foreword and Preface Foreword Who can argue with testing things before you allow yourself to depend on them? No onecanargue. No onewillargue. 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