Introduction | Writing Secure Code

In early 2004, Amit Yoran, then the director of the National Cyber Security Division at the U.S. Department of Homeland Security, announced that about 95 percent of software security bugs come from 19 common, well- understood programming mistakes. We are not going to insult your intelligence and explain the need for secure software in todays interconnected worldwe assume you know the reasonsbut we will outline how to find and remedy these common security defects in your code.

The worrisome thing about security defects is they are really easy to make, and the results of a very simple one-line error can be catastrophic. The coding defect that led to the Blaster worm was two lines long.

If there is only one bit of wisdom we can offer you, its this: No programming language or platform will make your software secure for you. Only you can do that. There is a lot of literature on creating secure software, and the authors of this book have written some of the most influential material, but there is a need for a small, easy-to-read, pragmatic book on the subject that covers all the bases quickly.

When writing this book, we stuck by a simple set of rules to keep it pragmatic:

Keep it simple. We didnt focus on unnecessary drivel. There are no war stories, no funny anecdotes; its just the pertinent facts. You probably just want to get your job done, and wish to make your code as a good as possible in the shortest amount of time; hence we kept the book simple so you can refer to it rapidly and get the facts you need.
Keep it short. A follow-on from the previous point: by focusing on the facts, and nothing else, we were able to keep the book short. In fact, well keep this introduction short too.
Make it cross platform. The Internet is a complex place, with myriads of interconnected computing devices running different operating systems and written using many programming languages. We wanted to make this book appeal to all developers, so the examples in this book apply to most operating systems.
Make it cross language. A follow-on from the previous point: most examples apply to different languages, and we show plenty of security defects in numerous languages throughout the book.

Book Layout

Each chapter outlines one Deadly Sin. There is no real ordering to the Sins, but we tried to keep the most heinous at the start of the book. Each chapter is then broken up into small sections:

Overview A brief introduction to the Sin, and why the Sin is, well, a Sin!
The Sin Explained The core essence of the defect; what the principle mistake is that makes this Sin so sinful.
Sinful Programming Languages A list of the languages inflicted by this Sin.
Sample Code Defects Concrete sinful examples in different languages, on different platforms.
Spotting the Defect Pattern Instructions on core things to look for in the code that lead to the defect.
Spotting the Defect During Code Review Pretty obvious, really: what to look for in your own code to spot the Sin. We know developers are busy so we keep these sections very short and to the point.
Testing the Defect During Test The tools and testing techniques you can use to test for this kind of Sin.
Example Defects Real-world Sin examples from the Common Vulnerabilities and Exposures (CVE) database (www.cve.mitre.org), BugTraq (www.securityfocus.com), or Open Source Vulnerability Database (www.osdvb.org) of this kind of defect, with some commentary from us. Note: At the time of writing, the CVE database is considering switching from using CAN and CVE numbers to using just CVE numbers , effective October 15, 2005. If this happens, then any reference to a CAN should be replaced with a CVE. For example, if you cant find CAN-2004-0029 (a bug in Lotus Notes when running on Linux), then try CVE-2004-0029.
Redemption Steps How to fix the problem in code to remove the Sin. Again, we show numerous remedies in numerous languages.
Extra Defensive Measures Other defenses you can put in place that do not fix the problem per se, but may make it harder for a bad guy to exploit a potential defect, or act as a backstop in case you make a mistake.
Other Resources This book is short, so we provide pointers to more reading and information, such as other book chapters, research papers, and web links.
Summary This is a really important part of each chapter, and you should refer to this section often. It is a list of dos, do nots and considers when writing new code or code reviewing older code. Do not underestimate the value of this section! These summary sections are also compiled in Appendix B.