19 Deadly Sins of Software Security

In each chapter, the authors break the content in the following sections: a brief overview of the sin, what languages it affects, a more detailed explanation of the programming flaw being exploited, related flaws, how to catch (or "spot" the exploit or flaw), sample code of the flaw, how to resolve the uncovered flaw, and how to take other defensive measures to remediate the issues.

Nothing in the book is groundbreaking, and much of it goes back to the foundations of good information security. For example, in the chapter "Sin 11: Use of Weak Password-Based Systems", they recommend remediating the detected flaws by using multi-factor authentication, and then go on to discuss the three classes of authentication technologies: things that you know, things that you have, and things that you are. But because this is not groundbreaking, and yet the authors need to go back to this basic concept to illustrate a point, this highlights the shortcomings that the authors are trying to address.

Another good chapter in the book is an earlier chapter, Chapter 6, which deals with poor application error handling. In this chapter, the authors discuss the six poor error handling behaviors: giving away too much information, ignoring the error outright, misinterpreting errors, using irrelevant error values, handling the wrong exceptions, and handling all of the exceptions. The authors detail and explain each of the error sub-categories and give plenty of examples of each.

The authors use the word lazy a couple of times, and it looks like from their viewpoint, a lot of the issues identified in the book could be fixed with lack of laziness in the part of the programmers, or better education. This is highlighted in the chapter "Sin 12: Failing to Store and Protect Data Securely" , which the authors take a hypothetical example and give the lazy/uneducated behavior. Suppose that your app needs to connect to a database server that requires a password, or access a protected network share using a password. The lazy and simplest and worst way to go about doing this to accomplish the goal is to hardcode the secret data as part of the application code. In addition to being a poor security practice, this will also scale to be a huge maintenance nightmare.

The last sin deals with user usability, which is not tied to any specific language. However, this deals with the soft side of programming, which discusses user behavior when he or she is faced with vague or unclear or unusable security advice or choices. In the absence of information, the user is most likely to hit "OK" or "Proceed" to bypass security controls.