cat slave diary

Reviewed 29th July 2005 @ Blackhat.

Introduction

Any text from the authors of Writing Secure Code and Building Secure Software (amongst others) is always welcome. I was looking forward to obtaining and reading the book. Both of my copies of Writing Secure Code are well thumbed, so I had high hopes.

I bought the book at Black Hat, and skimmed through at various slow sessions during the day. After skimming the entire thing and reading several of the chapters thoroughly, I think I have a reasonable handle on the work, but I reserve the right to change my opinion over time as I use it on some real world projects. I hope my opinion changes. That’s not to say that the book is bad (for it is clearly not a bad book, particularly when you consider the intended audience), it’s simply not what I had imagined.

I am a car nut, and I buy far too many car magazines. One thing that really irks me about car magazines is that they go on (and on … and on … and on) about cars that are impossible for the average punter to buy, sell like 12 hand built examples in a year, and are impossible for the privileged few owners to live with by any rational car buying context. Five bags of shopping in your Ferrari or Lambo? Not considered. Can it do four wheel powerslides? Sure can. The writers of these car magazines then often write dismissive crap about the normal every day cars you and I buy, saying that’s it not track focused or the seats are a bit too slidey when you’ve got the back wheels hanging out going around a hairpin turn way too fast. Theirs is not a normal world and is not representative of how the owners of normal cars will use them. I like reviews that deal with the expected users and write to their needs and wants, not as if you’re reviewing every car (book) as if it were a Ferrari zooming around the Nuremburg Ring. Therefore, I’ve made this review talk to who I believe the intended audience to be: the average PHP, Java, or .NET programmer working on a smallish project. Others may find this review useful.

Full disclosure time: I am the lead author of the OWASP Guide 2.0, which some may (incorrectly) consider a competitor to the 19 Sins. Now that I’ve had some time with the book, I know that a closer competitor within the OWASP stable is the OWASP Top 10, which is getting long in the tooth and is in the process of being updated.

When Michael blogged in early July that they had just finished a book, with huge names like Howard and LeBlanc and Viega… I really thought three years of Guide development might go down the drain, particularly if they’d done the equivalent of webifying Writing Secure Code for their 3rd edition. Now that I’ve read a goodly portion of 19 Sins, I’m breathing a huge sigh of relief in some ways, and disappointed in other ways. Read on to find out why.

What’s good

The language in the book is clear and easily understood. I loved the simple non-technical language – my boss will understand each and every topic. This is excellent for those of us who have a hard time getting the business to change as they don’t see the risk. Giving them an easy to understand book chapter to read or skim is a huge improvement. If only all security texts were this clear!

The authors have developed and extended the OWASP Top 10 approach – each chapter is about a single weakness or vulnerability (“sin”) pattern with essential advice to resolve or mitigate the pattern. Each chapter has many sections compared to the Top 10:

• Overview of the sin *
• Affected languages *
• The Sin Explained *
• Spotting the Sin Pattern
• Spotting the Sin during code review
• Testing techniques to find the sin
• Example Sin *
• Redemption Steps *
• Extra Defensive Measures
• Other resources *
• Summary *

* Full or partial OWASP Top 10 equivalent section

Each of the 19 sections deal with one “sin” pattern, such as Buffer overflows, or Failure to Handle Errors. This is a good idea, and makes it easy to understand the issues relating to a particular faulty pattern. As each chapter is only 15-20 pages long, it is not out of the question for a normal person to understand the issue at hand.

I really like the numerous examples in many different languages and platforms (such as Linux and MacOS X coverage!), and how to find the issue from a “grep” point of view. This is a huge improvement over the Win32 focused Writing Secure Code. This alone makes this book an essential read for Java and PHP programmers who have a distinct dearth of acceptable security references.

Race conditions are a forgotten realm for web applications. I must admit the OWASP materials do not deal with it at all, which is a mistake. TOCTOU and race conditions are applicable in any language and framework.

There are several other chapters which I appreciated as they don’t get that much air time as they aren’t that sexy. For example, usability issues. If users hate your software or controls, they will get around it. If they make too many mistakes, you lose security. The chapter delves into some common errors – asking too much of your average user, and assuming that the user is able to make certain types of decisions. This chapter is a welcome topic.

I also liked the appendix that maps the book to the OWASP Top 10, and they referenced OWASP several times in the references section. But you know I’m biased

What’s not so good

Although the book is very understandable which is essential for communicating with the business, there are no common business risks in this book that lead to direct business loss, such as phishing or credit card controls. This may be due to the technical nature of the book, but I feel some treatment of business risk is essential in any secure solution design. You might have a “secure” technical solution that passes penetration tests, but loses the business a million dollars a month as the attackers attack weak business rules or inappropriately trusted elements.

I feel that some of the “sin” patterns are the same or so closely related that they should have been coalesced. Buffer overflows and format strings (sin 1 and 2) are essentially the same pattern – buffer overflows. Ditto “SQL injection” and “Command Injection”, and “Failing to protect network traffic” and “Improper use of SSL / TLS”. Remember, patterns are meta-concepts, not specific instances. I class all three known XSS problems (reflected, stored, DOM) as the same pattern, and pretty much all injection patterns (User agent, SQL, LDAP, XML, etc) under the same pattern heading, even though they use different techniques and sequences to exploit vulnerable software. However, that’s just my tastes. I’m sure the authors had a good reason for making the headings just so.

The book bills itself as being complete. I feel it is not. It is missing some injection issues, such as LDAP and XML injection, which is a relatively unexplored attack frontier.

Book blurb:

“Secure your software … from the start. This essential book outlines the 19 sins of software security and details how to fix each one”.

(my emphasis in bold)

Michael Howard wrote in his blog:

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.

There are more than just 19 bad web application security patterns, so I don’t think it is complete or covers all the bases. I probably would not brought this up if the book didn’t suggest that it’s all you really need. It probably does cover 90% of the major issues out there, though, so the book definitely has value.

XSS, which is a major – but not the sole – phishing attack vector, has a prominent and mostly useful chapter, particularly if you’ve never dealt with XSS before. However, the index does not point to the XSS chapter under the heading “phishing”. Hopefully, an improved index will be in the second edition. The XSS chapter deals mainly with reflected XSS injection, although they do discuss stored XSS without naming it explicitly and they don’t mention stored XSS in the pattern. DOM XSS injection (which is pretty new, I suppose) is not discussed.

The book has no discussion on attack surface reduction or threat modeling. I feel this is a mistake. The only threat modeling note is a single offhand sentence in remediating high level design errors on page 172 in the Failing to protect data chapter:

The best approach to solving design-level problems is threat modeling.

There are no references to the relevant or recommended TM texts, which makes it hard for a new programmer to go find the necessary information. Threat modeling is not in the summary bullet points. One of the most effective application security controls is therefore essentially not covered. I am dealing with TM with a heavily abused (17 releases in three years) open source product right now, and attack surface reduction and TM are key elements of reducing the risk of this application and finding the weaknesses. Time will tell if my approach (which is actually derived from Writing Secure Code) is right.

The 19 Deadly Sins is a useful text … for the technical threats of circa 2004. By necessity any text which deals with issues by looking at past vulnerabilities will reflect past history, rather than inspect attack patterns and research. As researchers such as Amit Klein have demonstrated, there is new stuff coming up, and Bruce Schneier is always ranting about governments and firms putting excessive controls on attack methods of the past rather than spending the time and money to look forward. 19 Sins does nothing to address these issues.

Lastly, the negative stance (“Sins”) I feel is not helpful to human nature. If you want the owners of vulnerable business systems to come along for the ride, you have to couch your findings in a positive spin (“enabling secure business”) not the negative (“your software is sinful”). That’s why the OWASP Guide 2.0 is mostly positive in its approach (thou should… rather than thou shalt not…), and if I have anything to do with the Top 10 revision, it’ll also stop being a negative document.

Conclusion

I feel strong discomfort in damning a book with faint praise, particularly when the book is written by giants in the field. I know first hand how incredibly Hard™ it is to write books. It is generally thankless and there are so many little things to make sure are right. I am sure that many people will think “hey, but this guy writes on a very similar topic … follow the money”, well please take your blinkers off. I don’t earn anything from the OWASP Guide 2.0, and I imagine if Michael, John or Dave reviewed the Guide they’d rightly find much to be amused at. The Guide 2.0 is a volunteer driven effort and is in need of polishing, which I hope to do over the next few months.

I want all ISVs, solution architects, and developers to write secure software and I don’t mind where that advice comes from as long as the developers use the advice. This book is useful, but is not the sole answer to writing secure software. The book is missing key elements of secure software development, such as “don’t implement insecure or overly risky business processes”, security architecture, threat modeling, and offers no new advice for solving some of highest risk problems businesses face today.

For PHP and Java programmers, and developers of low to medium protected targets (such as blogs, forums, and so on), this book is a great reference. For ISVs and developers of high value and highly protected systems, this book is a great start, but falls short of required levels of protection for those apps. You will still need Writing Secure Code and OWASP Guide 2.0. That’s no bad thing, but I was hoping for a new single reference to recommend all developers.

I don’t regret buying the book, and I strongly recommend it to our Java and PHP colleagues who have so few security books or references of any type. However, I will impatiently await Writing Secure Code 3rd edition!

3/5 stars.