Summary

Creating secure code requires more than just good intentions. Programmers need to know that their code will be safe in an almost infinite number of scenarios and configurations. Static source code analysis gives users the ability to review their work with a fine-toothed comb and uncover the kinds of errors that lead directly to security vulnerabilities. Now, there's a complete guide to static analysis: how it works, how to integrate it into the software development processes, and how to make the most of it during security code review.

Author Biography

B rian Chess is a founder of Fortify Software. He currently serves as Fortify’s Chief Scientist, where his work focuses on practical methods for creating secure systems. Brian holds a Ph.D. in Computer Engineering from the University of California at Santa Cruz, where he studied the application of static analysis to the problem of finding security-relevant defects in source code. Before settling on security, Brian spent a decade in Silicon Valley working at huge companies and small startups. He has done research on a broad set of topics, ranging from integrated circuit design all the way to delivering software as a service. He lives in Mountain View, California.

J acob West manages Fortify Software’s Security Research Group, which is responsible for building security knowledge into Fortify’s products. Jacob brings expertise in numerous programming languages, frameworks, and styles together with knowledge about how real-world systems can fail. Before joining Fortify, Jacob worked with Professor David Wagner at the

University of California at Berkeley to develop MOPS (MOdel Checking Programs for Security properties), a static analysis tool used to discover security vulnerabilities in C programs. When he is away from the keyboard, Jacob spends time speaking at conferences and working with customers to advance their understanding of software security. He lives in San Francisco, California.

Software Security and Static Analysis	p. 1
The Software Security Problem	p. 3
Defensive Programming Is Not Enough	p. 4
Security Features != Secure Features	p. 6
The Quality Fallacy	p. 9
Static Analysis in the Big Picture	p. 11
Classifying Vulnerabilities	p. 14
The Seven Pernicious Kingdoms	p. 15
Summary	p. 19
Introduction to Static Analysis	p. 21
Capabilities and Limitations of Static Analysis	p. 22
Solving Problems with Static Analysis	p. 24
Type Checking	p. 24
Style Checking	p. 26
Program Understanding	p. 27
Program Verification and Property Checking	p. 28
Bug Finding	p. 32
Security Review	p. 33
A Little Theory, a Little Reality	p. 35
Success Criteria	p. 36
Analyzing the Source vs. Analyzing Compiled Code	p. 42
Summary	p. 45
Static Analysis as Part of the Code Review Process	p. 47
Performing a Code Review	p. 48
The Review Cycle	p. 48
Steer Clear of the Exploitability Trap	p. 54
Adding Security Review to an Existing Development Process	p. 56
Adoption Anxiety	p. 58
Start Small, Ratchet Up	p. 62
Static Analysis Metrics	p. 62
Summary	p. 69
Static Analysis Internals	p. 71
Building a Model	p. 72
Lexical Analysis	p. 72
Parsing	p. 73
Abstract Syntax	p. 74
Semantic Analysis	p. 76
Tracking Control Flow	p. 77
Tracking Dataflow	p. 80
Taint Propagation	p. 82
Pointer Aliasing	p. 82
Analysis Algorithms	p. 83
Checking Assertions	p. 84
Naive Local Analysis	p. 85
Approaches to Local Analysis	p. 89
Global Analysis	p. 91
Research Tools	p. 94
Rules	p. 96
Rule Formats	p. 97
Rules for Taint Propagation	p. 101
Rules in Print	p. 103
Reporting Results	p. 105
Grouping and Sorting Results	p. 106
Eliminating Unwanted Results	p. 108
Explaining the Significance of the Results	p. 109
Summary	p. 113
Pervasive Problems	p. 115
Handling Input	p. 117
What to Validate	p. 119
Validate All Input	p. 120
Validate Input from All Sources	p. 121
Establish Trust Boundaries	p. 130
How to Validate	p. 132
Use Strong Input Validation	p. 133
Avoid Blacklisting	p. 137
Don't Mistake Usability for Security	p. 142
Reject Bad Data	p. 143
Make Good Input Validation the Default	p. 144
Check Input Length	p. 153
Bound Numeric Input	p. 157
Preventing Metacharacter Vulnerabilities	p. 160
Use Parameterized Requests	p. 161
Path Manipulation	p. 167
Command Injection	p. 168
Log Forging	p. 169
Summary	p. 172
Buffer Overflow	p. 175
Introduction to Buffer Overflow	p. 176
Exploiting Buffer Overflow Vulnerabilities	p. 176
Buffer Allocation Strategies	p. 179
Tracking Buffer Sizes	p. 186
Strings	p. 189
Inherently Dangerous Functions	p. 189
Bounded String Operations	p. 195
Common Pitfalls with Bounded Functions	p. 203
Maintaining the Null Terminator	p. 213
Character Sets, Representations, and Encodings	p. 218
Format Strings	p. 224
Better String Classes and Libraries	p. 229
Summary	p. 233
Bride of Buffer Overflow	p. 235
Integers	p. 236
Wrap-Around Errors	p. 236
Truncation and Sign Extension	p. 239
Conversion between Signed and Unsigned	p. 241
Methods to Detect and Prevent Integer Overflow	p. 242
Runtime Protection	p. 251
Safer Programming Languages	p. 251
Safer C Dialects	p. 255
Dynamic Buffer Overflow Protections	p. 258
Dynamic Protection Benchmark Results	p. 263
Summary	p. 263
Errors and Exceptions	p. 265
Handling Errors with Return Codes	p. 266
Checking Return Values in C	p. 266
Checking Return Values in Java	p. 269
Managing Exceptions	p. 271
Catch Everything at the Top Level	p. 272
The Vanishing Exception	p. 273
Catch Only What You're Prepared to Consume	p. 274
Keep Checked Exceptions in Check	p. 276
Preventing Resource Leaks	p. 278
C and C++	p. 279
Java	p. 283
Logging and Debugging	p. 286
Centralize Logging	p. 286
Keep Debugging Aids and Back-Door Access Code out of Production	p. 289
Clean Out Backup Files	p. 292
Do Not Tolerate Easter Eggs	p. 293
Summary	p. 294
Features and Flavors	p. 295
Web Applications	p. 297
Input and Output Validation for the Web	p. 298
Expect That the Browser Has Been Subverted	p. 299
Assume That the Browser Is an Open Book	p. 302
Protect the Browser from Malicious Content	p. 303
HTTP Considerations	p. 319
Use POST, Not GET	p. 319
Request Ordering	p. 322
Error Handling	p. 322
Request Provenance	p. 327
Maintaining Session State	p. 328
Use Strong Session Identifiers	p. 329
Enforce a Session Idle Timeout and a Maximum Session Lifetime	p. 331
Begin a New Session upon Authentication	p. 333
Using the Struts Framework for Input Validation	p. 336
Setting Up the Struts Validator	p. 338
Use the Struts Validator for All Actions	p. 338
Validate Every Parameter	p. 342
Maintain the Validation Logic	p. 343
Summary	p. 346
XML and Web Services	p. 349
Working with XML	p. 350
Use a Standards-Compliant XML Parser	p. 350
Turn on Validation	p. 352
Be Cautious about External References	p. 358
Keep Control of Document Queries	p. 362
Using Web Services	p. 366
Input Validation	p. 366
WSDL Worries	p. 368
Over Exposure	p. 369
New Opportunities for Old Errors	p. 370
JavaScript Hijacking: A New Frontier	p. 370
Summary	p. 376
Privacy and Secrets	p. 379
Privacy and Regulation	p. 380
Identifying Private Information	p. 380
Handling Private Information	p. 383
Outbound Passwords	p. 388
Keep Passwords out of Source Code	p. 389
Don't Store Clear-Text Passwords	p. 391
Random Numbers	p. 397
Generating Random Numbers in Java	p. 398
Generating Random Numbers in C and C++	p. 401
Cryptography	p. 407
Choose a Good Algorithm	p. 407
Don't Roll Your Own	p. 409
Secrets in Memory	p. 412
Minimize Time Spent Holding Secrets	p. 414
Share Secrets Sparingly	p. 415
Erase Secrets Securely	p. 416
Prevent Unnecessary Duplication of Secrets	p. 418
Summary	p. 420
Privileged Programs	p. 421
Implications of Privilege	p. 423
Principle of Least Privilege	p. 423
This Time We Mean It: Distrust Everything	p. 426
Managing Privilege	p. 427
Putting Least Privilege into Practice	p. 427
Restrict Privilege on the Filesystem	p. 433
Beware of Unexpected Events	p. 436
Privilege Escalation Attacks	p. 439
File Access Race Conditions	p. 440
Insecure Temporary Files	p. 446
Command Injection	p. 450
Standard File Descriptors	p. 452
Summary	p. 454
Static Analysis in Practice	p. 457
Source Code Analysis Exercises for Java	p. 459
Installation	p. 460
Begin with the End in Mind	p. 461
Auditing Source Code Manually	p. 469
Running Fortify SCA	p. 471
Understanding Raw Analysis Results	p. 472
Analyzing a Full Application	p. 478
Tuning Results with Audit Workbench	p. 479
Auditing One Issue	p. 483
Performing a Complete Audit	p. 487
Writing Custom Rules	p. 491
Answers to Questions in Exercise 13.2	p. 499
Source Code Analysis Exercises for C	p. 503
Installation	p. 504
Begin with the End in Mind	p. 505
Auditing Source Code Manually	p. 513
Running Fortify SCA	p. 514
Understanding Raw Analysis Results	p. 515
Analyzing a Full Application	p. 520
Tuning Results with Audit Workbench	p. 521
Auditing One Issue	p. 525
Performing a Complete Audit	p. 529
Writing Custom Rules	p. 531
Answers to Questions in Exercise 14.2	p. 537
Epilogue	p. 541
References	p. 545
Index	p. 559
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

Preface Preface Following the light of the sun, we left the Old World. --Christopher Columbus We live in a time of unprecedented economic growth, increasingly fueled by computer and communications technology. We use software to automate factories, streamline commerce, and put information into the hands of people who can act upon it. We live in the information age, and software is the primary means by which we tame information. But oddly enough, much of the activity that takes place under the guise of computer security isn't really about solving security problems at all; it's about cleaning up the mess that security problems create. Virus scanners, firewalls, patch management, and intrusion-detection systems are all means by which we make up for shortcomings in software security. The software industry puts more effort into compensating for bad security than it puts into creating secure software in the first place. Do not take this to mean that we see no value in mechanisms that compensate for security failures. Just as every ship should have lifeboats, it is both good and healthy that our industry creates ways to quickly compensate for a newly discovered vulnerability. But the state of software security is poor. New vulnerabilities are discovered every day. In a sense, we've come to expect that we will need to use the lifeboats every time the ship sails. Changing the state of software security requires changing the way software is built. This is not an easy task. After all, there are a limitless number of security mistakes that programmers could make! The potential for error might be limitless, but in practice, the programming community tends to repeat the same security mistakes. Almost two decades of buffer overflow vulnerabilities serve as an excellent illustration of this point. In 1988, the Morris worm made the Internet programming community aware that a buffer overflow could lead to a security breach, but as recently as 2005, buffer overflow was the number one cause of security problems cataloged by the Common Vulnerabilities and Exposures (CVE) Project CWE, 2006. This significant repetition of well-known mistakes suggests that many of the security problems we encounter today are preventable and that the software community possesses the experience necessary to avoid them. We are thrilled to be building software at the beginning of the twenty-first century. It must have felt this way to be building ships during the age of exploration. When Columbus came to America, exploration was the driving force behind economic expansion, and ships were the means by which explorers traveled the world. In Columbus's day, being a world economic power required being a naval power because discovering a new land didn't pay off until ships could safely travel the new trade routes. Software security has a similar role to play in today's world. To make information technology pay off, people must trust the computer systems they use. Some pundits warn about an impending "cyber Armageddon," but we don't fear an electronic apocalypse nearly so much as we see software security as one of the primary factors that control the amount of trust people are willing to place in technology. Without adequate security, we cannot realize the full potential of the digital age. We believe that it is the responsibility of the people who create software to make sure that their creations are secure. Software security cannot be left to the system administrator or the end user. Network security, judicious administration, and wise use are all important, but in the long run, these endeavors cannot succeed if the software is inherently vulnerable. Although security can sometimes appear to be a black art or a matter of luck, we hope to show that it is neither. Making security sound impossible or mysterious is giving