The 19 Deadly Sins of Software Security

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:

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.

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.

Comments (27)

  1. Can we see examples of the 19 sins in C# as an example?

  2. Ahhhhh… it was time for me to read a new software security book. I was just thinking about what was next to read. Tonight Michael Howard helped me out and told the world about a new book that he, David LeBlanc and John Viega have finished writing called "The 19 Deadly Sins of Software Security". The book is carved up into 19 chapters, or Sins, and each is only 10-15pp long. The Sins are: Buffer Overflows Format String problems SQL injection Command injection Failure to handle errors Cross-site scripting Failing to protect network traffic Use of "magic" URLs and hidden forms Improper use of SSL Use of weak password-based systems Failing to store and protect data Information leakage Improper file access Integer range errors Trusting network address information Signal race conditions Unauthenticated key exchange Failing to use cryptographically strong random numbers Poor usability These three guys have contributed to some of my favorite writings. I look forward to getting my hands on a copy….

  3. Ilya says:

    Chapter 18 rather should be "Failing to use cryptography in a proper way" though 🙂 Random numbers is a way too narrow spot at the whole subject’s blunders.

  4. Uwe Hermann says:

    Michael Howard, David LeBlanc and John Viega have written a book called The 19 Deadly Sins of Software Security, which is to be published soon.
    It explains the most important security issues one encounters in the software industry in a Design Patterns-lik

  5. The work you did on WSC was eye opening and great stuff. However, I like the format you’ve chosen for this. You guys have this down to a science. I can’t wait!

  6. Michael Howard, Microsoft’s security expert, is working on a new book called The 19 deadly sins of software security. Get a copy for your IT guy. Here are Howard’s deadly sins: 1. Buffer Overflows 2. Format String problems 3. SQL…

  7. Visual Studio Team System

    There’s a new Team System community site –! ⊕


  8. michaelsilk says:

    how can you say it’s aimed a ‘all languages’ and then put the #1 ‘sin’ as "buffer overflow" and #2 as format string!!

    not really that language independant (so don’t try to be ..?!).


  9. Congratulations to the writer of the book "19 deadly sins". I’m probably wasting my time making my comments which are not an attack on his book or on his idea. My comments are basically on the refusal of everypne to recognize that the hackers operate not because of the foolishness of anyone as the book implies. It is because the present system of browsing the net gives to much power who has money to buy any personal coputer that is powered by any browser. The web surfer can use any security system he can find on the net. If he is clever like the writer of the "19 deadly sins" he will device his own security software and market it through Amazon like our friend Michael does and become rich. May be not overnight but eventually.

    Unless this power is taken away from the Hackers the security systems will do no good. The hackers job is relatively easy. It is to convince the servers that the request for any information is legitemate. There are no holds barred by the request for inormation. Perhaps Michael would agree with me that this is the job of the server. Send the files to the clients. But may be Michael would not agree with me. In that case I’d ask him to tell me and others what, in his view, is the job of the server?

    Unless the job of the server is changed, basically by the rewriting of the code, there is no hope for the people who keep their files on the internet.

    <a href="">STOP THE HACKER</a>

    Perhaps I should have called my blog "ONLY ONE WAY TO STOP THE HACKERS.

  10. Sergey Kostrukov says:

    Bla, Bla, Bla…

    I has read "Writing Secure Code" book, and was interested. – thanks, Michael, for the good book.

    I’ll keep waiting, when this book will be published in Russian.

  11. Here’s an invaluable resource…an article by Michael Howard titled Browsing the Web and Reading E-mail Safely as an Administrator. The article includes a great application called DropMyRights that lets a user who is running as administrator run applications in the much safer context of a non-administrator…

  12. [Nacsa Sándor, 2009. január 13. – február 3.]&#160; A minőségbiztosítás kérdésköre szinte alig ismert

Skip to main content