Customer Reviews

19 Deadly Sins of Software Security: Programming Flaws and How to Fix Them (Security One-off)

5 star:		(7)
4 star:		(5)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

I read six books on software security recently, namely "Writing Secure Code, 2nd Ed" by Michael Howard and David LeBlanc; "19 Deadly Sins of Software Security" by Michael Howard, David LeBlanc, and John Viega; "Software Security" by Gary McGraw; "The Security Development Lifecycle" by Michael Howard and Steve Lipner; "High-Assurance Design" by Cliff Berg; and "Security Patterns" by Markus Schumacher, et al. Each book takes a different approach to the software security problem, although the first two focus on coding bugs and flaws; the second two examine development processes; and the last two discuss practices or patterns for improved design and implementation. My favorite of the six is Gary McGraw's, thanks to his clear thinking and logical analysis. The other five are still noteworthy books. All six will contribute to the
production of more security software.

The main reason to read 19DS is to quickly become acquainted with various security problems facing software developers. At less than 300 pages, it's not a thick tome like WSC2E. 19DS also is not afraid to mix bugs (coding errors, like buffer overflow conditions) with flaws (design problems, like "failing to protect network traffic.") This sort of lax categorization bothers me (and Gary McGraw, as noted in his book "Software Security"), but it shouldn't interfere with the quality content of 19DS.

Probably the most interesting aspect (to me) of 19DS was sin 10, which discussed problems with Secure Sockets Layer (SSL). The chapter didn't describe algorithmic or protocol problems. Instead, it explained how programmers make poor assumptions about the features provided by their language of choice with respect to SSL. For example, many SSL libraries do not properly validate certificates. Without this functionality, the authors argue that SSL is almost worthless. While I don't necessarily agree with this statement, I really like reading this sort of criticism. I'd like to note that p 134 berates Python's ssl() but ignores pyOpenSSL, which probably provides the features the authors would want.

Other "sins" take slightly different looks at security issues. Sin 17, for example, explains the importance of key exchange AND authentication. These are the sorts of problems I imagine are only discovered by examining multiple real-world implementations, and I value the authors sharing their experiences.

I subtracted one star because the quality of the "sins" isn't even. Some don't adequately explain the problem at hand (e.g., integer overflows). If the authors assume the reader knows the problem well enough to not introduce it properly, then why discuss it at all?

Overall, however, 19DS is a great book to get to your developers. It's short enough that they might actually read it, and the content is presented in a convincing enough manner to perhaps influence their coding choices.

If George Santayana were to recommend a security book, it would certainly be 19 Deadly Sins of Software Security. Santayana is the poet-philosopher widely known for saying, "Those who cannot remember the past are condemned to repeat it." For far too long, software developers have been making the same mistakes in programming as if they were incapable of remembering their past errors.

Poorly written software lies behind nearly every computer security vulnerability. Amit Yoran, former director of the National Cyber Security Division of the U.S. Department of Homeland Security, is quoted as saying that "95 percent of software bugs are caused by the same 19 programming flaws." These flaws are the so-called "deadly sins" of the title.

The book covers these 19 programming flaws, which include the most devastating types of coding and architectural errors, such as buffer overflows, format string problems, cross-site scripting, and insufficient encryption. Each flaw gets its own chapter, which features a brief introduction to the problem, sample code depicting each "sin," ways to detect the problem during code review, a description of tools and techniques to test for the defect, and defensive measures that make it more difficult for someone to exploit the weakness.

None of the text is extraneous, as it economically addresses a wealth of the most popular platforms and languages. These include Windows, Linux, UNIX, C/C++, C#, Java, PERL, and more.

Software applications developers, irrespective of which platform or language they use to write code, should consider this book required reading. Were he a techie, Santayana might have said that those who have written insecure code in the past are condemned to continue to write insecure code in the future. Programmers need only read this book to help put an end to that vicious cycle.

With the continual alerts and patches for software vulnerabilities, it may appear that there is no way to write secure software. While I agree there are no "absolutes" when it comes to secure software, there are ways to greatly reduce your potential of writing software that can be exploited. 19 Deadly Sins Of Software Security - Programming Flaws and How To Fix Them by Michael Howard, David LeBlanc, and John Viega does an excellent job in helping you focus in on this subject...

Content: Buffer Overruns; Format String Problems; Integer Overflows; SQL Injection; Command Injection; Failing To Handle Errors; Cross-Site Scripting; Failing To Protect Network Traffic; Use Of Magic URLs And Hidden Form Fields; Improper Use Of SSL And TLS; Use Of Weak Password-Based Systems; Failing To Store And Protect Data Security; Information Leakage; Improper File Access; Trusting Network Name Resolution; Race Conditions; Unauthenticated Key Exchange; Cryptographically Strong Random Numbers; Poor Usability; Mapping The 19 Deadly Sins To The OWASP "Top Ten"; Summary Of Do's And Don'ts; Index

This book came out of a list developed by Homeland Security that declared that 95% of security issues in software came from 19 programming mistakes. What you read in these pages go into more detail about each of those issues, but in a very concise, practical, no-nonsense fashion. This is the type of information you'll need as a professional who needs to get a job done without wasting time on fluff and verbose writing. Each chapter covers one of the sins, and follows a standard format for the information. The subsections in each chapter are: Overview of the Sin; Affected Languages; The Sin Explained; Related Sins; Spotting the Sin Pattern; Spotting the Sin During Code Review; Testing Techniques to Find the Sin; Example Sins; Redemption Steps; Extra Defensive Measures; Other Resources; Summary. Since each chapter stands on its own, you can use this as a reference tool if you're having a particular issue to resolve, or you can read it cover to cover to get a good understanding of the security concerns you need to face when programming.

Just about every significant programming platform and language is covered somewhere in here (Windows, Unix, Linux, C, C++, C#, Java, PHP, Perl, etc.), so there's no real reason why nearly every developer won't take *something* away from their reading. And if you're writing software that will be exposed to usage outside your company, there is *no* reason to not have this book on your shelf. You'll get the core of what you should do very quickly, and you'll end up writing more secure software up front instead of issuing patch after patch after patch...

This book's a must-have addition to your bookshelf if you're at all concerned about developing secure software -- and you ought to be.

The book's format lends to quick reading of the most common security errors. Each "sin" breaks down into concise sections laying out an overview of the sin, what languages are effected, examples of the sin, redemption steps, extra defense measures, other resources on the sin, and a summary of the sin.

Most useful to me as a developer are the sections on patterns for spotting the sin, how to look for the sin during code reviews, and how to test for the sin.

The book's strengths are its concise discussion of each sin, and it's almost-cookbook format. You're able to quickly find exactly what you need in the book. The book also covers a wealth of languages: C/C++, C#, Java, Perl, VB/VB.NET, plus quite the major different platforms: Macs, *nix, and Windows.

The concise nature of the book is also its weakness. Some of the examples aren't explained very well -- it's expected that the reader is experienced enough to figure out exactly what the errors are. This may overwhelm developers new to a particular language if they're not motivated enough to track down further information.

However, more information and examples would weigh this book down and make it less attractive and useful. Use this book as a general (and sometimes specific) guide, but look elsewhere for specifics on implementation.

If you are serious about eradicating software security bugs, you should buy this book. Keeping an eagel eye on the bug parade is a critical activity in software security. (Just don't forget about design flaws while you're at it.)

Mike Howard, David LeBlanc, and John Viega are all top notch software security experts. Listen carefully. Be the bug.

The software security touchpoints help address problems like these every day.

I am not a security type, I look at code for robustness. Security bugs are BUGS that have a security component. I don't see an array overflow as a way for someone to crash my code, I see it as a problem where my code will act in an unpredictable way.

The first 3 chapters alone is worth the price of this book. I fount it an easy read that really made the issues stand out. I can see why there are so many security problems in software. This book not only described the problems, it did it in a way that showed me how common these problems are.

Everywhere I look, I now see interger overflow, and array bound issues. scanf and even printf are now suspect for me.

I think the name of the book will limit its audience. This book should be read by anyone looking to write good basic code.

I read the book as part of my Advanced Security course reading at the University of Saint Thomas. It is a short read, with chapters no longer than 10 to 15 pages, application security focused with code examples illustrating some of the issues, and recommendations (with references) for how to address each of the problems.

Overall, a good introduction to information about common security flaws and problems. Recommended for any software developer.

This is a very good book for software developers that are concerned about
software security. It is short enough and easy enough to follow that it
might also be a good book for software developers that are not concerned
about software security but should be. Last year I reviewed Seacord's
"Secure Coding in C and C++" and claimed it was "The best how-to security
book" I had seen. This one might be even better. It is almost as thorough
in the areas the two have in common, and has more material about the proper
use of third party security packages. There are extensive references to
books and papers about exploits and defenses, and pointers to many web
sites with additional and more detailed information. Highly recommended.

The authors take an even handed look across several major languages and point out pitfalls in each. Probably, for you as a programmer, you have met many of these ideas before. But maybe in the context of a given language. This book lets you take a metalanguage view.

Consider integer overflows. C# and Visual Basic guard against these. But not Java, C or C++. There are also commonsense recommendations like using unsigned integers when describing things that are intrinsically non-negative, like memory addresses or sizes of memory allocations. Alas, Java does not support unsigned integers.

Cross site scripting gets a chapter of its own. A dangerous phenomenon of the web. Where a web page gets user input from the user's browser. The application does not check this input for malicious content, and it proceeds to send it to a web page. The text might have scripting commands which are then run by the user's browser. These might mess up the browser or even the user's computer. Worth checking out.

Although the writing is at times atrociously bad, "19 deadly Sins of Software Security," by Howard, LeBlanc, and Viega, is a worthwhile read for software developers and IT managers. The book provides useful tips and background on software security vulnerabilities. And even where the literal meaning of passages is opaque or self-contradictory, the reader can most likely puzzle out useful information.

Not all the writing is bad. For example, the chapter on cross-site scripting is the clearest explanation of this threat that I have come across.

But sometimes, the writing is so bad that word choice appears to have been random. For example, here is a paragraph describing the problem with the SSL API:

"The problems with SSL are the fault of the API, not the underlying programming language. Therefore, any language can be affected. HTTPS APIs tend to be less problematic than generic SSL, because the HTTPS protocol mandates authentication checks that general-purpose SSL protocol leaves as optional. As a result, APIs tend to leave this responsibility up to the user."

I'm immediately put off by the phrase "underlying programming language" being used to describe the language calling an API, since the usual metaphor is that you call "down" into an API. The next sentence, about HTTPS being less problematic than generic SSL, makes sense, but how does this result in APIs leaving responsibilities to users?

No big deal: the gist is that it is not as easy to make security errors in HTTPS as it is with generic SSL libraries, although the passage does not speak well of the editors at McGraw Hill.

Examples of contractions include the use of regular expressions to locate problematic user input (don't use them because they are too hard to understand and hence prone to error; do use them because they are powerful) and quoting user input from web forms (it's easily circumvented, but do it). The point is that complex regular expressions may not match what you expect or what a malicious user can create, and quoting input is not sufficient protection.

I believe that a problem faced by "how-to" books on security is that the topics and tidbits do not sort out neatly into categories. Also, there are strengths and weaknesses to many of the mitigation strategies. And my guess is that engineers and techies get pushed into turning PowerPoint slides into paragraphs, even if there is not much logical connection between the bullet points of a slide.

That said, with his books "Applied Cryptography" and "Cryptography Engineering", Bruce Schneier has demonstrated that it is possible to write well and lucidly on some of the most difficult topics in computer security. If only more writers aspired his example!