After much blood, sweat and tears, a new software security book, written by me, David LeBlanc and John Viega went to the printers today, and should be available in time for Blackhat :) It has the ever-so catchy title of "The 19 Deadly Sins of Software Security."

Y'all probably know David, he was the co-author of Writing Secure Code with me. John is an old hat at this security stuff too, he's written a bunch of books mainly focusing on open source security, including Building Secure Software, Network Security OpenSSL and Secure Programming Cookbook for C and C++.

So why on earth did we write another book on the subject? Easy, we wanted a book the industry could use, John's an open source guy and David and I are primarily Windows guys and we wanted to create book that covered all popular languages *C, C++, C#, Java, PHP, Perl, VB etc) and all popular platforms (Windows, Linux, Unix and Mac OS X.)

The book is carved up into 19 chapters, or Sins, and each is only 10-15pp long. The Sins are:

  1. Buffer Overflows
  2. Format String problems
  3. SQL injection
  4. Command injection
  5. Failure to handle errors
  6. Cross-site scripting
  7. Failing to protect network traffic
  8. Use of "magic" URLs and hidden forms
  9. Improper use of SSL
  10.  Use of weak password-based systems
  11.  Failing to store and protect data
  12.  Information leakage
  13.  Improper file access
  14.  Integer range errors
  15.  Trusting network address information
  16.  Signal race conditions
  17.  Unauthenticated key exchange
  18.  Failing to use cryptographically strong random numbers
  19.  Poor usability

Each chapter is carved into the following sections:

Overview
A brief introduction to the problem, not too deep, limited to 6-12 paragraphs.

The Sin Explained
The core essence of the defect, what is the principle mistake that makes this A Bad Thing?

Sample Code Defect
Sample code. Use at least two languages if possible, and show variations if possible too.

Spotting the Defect Pattern
Outside of the defect itself, what designs must a developer follow to lead up to the vulnerability?

Spotting the Defect during Code Review
What to look for in code to spot the flaw. Remember, developers are time constrained, and in many instances knowledge constrained too, so anything you can do to make this step easier is good!

Testing the Defect during Test
Tools and techniques you can use to test for this kind of defect.

Example Defects
Examples from CVE or SecurityFocus of this kind of defect, with some commentary from us.

Redemption Steps
How to fix the problem in code. Once again, show many languages, and if possible, variants.

Extra Defensive Measures
Other defenses you can put in place that do not fix the problem, but may make it harder for a bad guy to exploit a potential defect.

Other Resources
Book chapters, web links etc.

Summary
A list of DO’s, DO NOT’s and CONSIDER’s

A critical design goal, from the outset, was to be short and to the point; no war stories, no gossip, just the facts.

We're very happy with this book, it's the first book to focus on the broad industry-wide issue of security and we believe it covers *ALL* the bases.

http://www.amazon.com/exec/obidos/tg/detail/-/0072260858