During February and March of 2002, all normal feature work on Microsoft Windows stopped. Throughout this period, the entire development team turned its attention to improving the security of the next version of the product, Windows .NET Server 2003. The goal of the Windows Security Push, as it became known, was to educate the entire team about the latest secure coding techniques, to find design and code flaws, and to improve test code and documentation. The first edition of this book was required reading by all members of the Windows team during the push, and this second edition documents many of the findings from that push and subsequent security pushes for other Microsoft products, including SQL Server, Office, Exchange, Systems Management Server, Visual Studio .NET, the .NET common language runtime, and many others.
The impetus for the Windows Security Push (and many of the other security pushes) was Bill Gates’s "Trustworthy Computing" memo of January 15, 2002, which outlined a high-level strategy to deliver a new breed of computer systems, systems that are more secure and available. Since the memo, both of us have spoken to or worked with thousands of developers within and outside Microsoft, and they’ve all told us the same thing: "We want to do the right thing—we want to build secure software—but we don’t know enough yet." That desire and uncertainty directly relates to this book’s purpose: to teach people things they were never taught in school—how to design, build, test, and document secure software. By secure software, we don’t mean security code or code that implements security features. We mean code that is designed to withstand attack by malicious attackers. Secure code is also robust code.
Our goal for this book is to be relentlessly practical. A side effect is to make you understand that your code will be attacked. We can’t be more blunt, so let us say it again. If you create an application that runs on one or more computers connected to a network or the biggest network of them all, the Internet, your code will be attacked.
The consequences of compromised systems are many and varied, including loss of production, loss of customer faith, and loss of money. For example, if an attacker can compromise your application, such as by making it unavailable, your clients might go elsewhere. Most people have a low wait-time threshold when using Internet-based services. If the service is not available, many will take their patronage and money to your competitors.
The real problem with numerous software development houses is that security is not seen as a revenue-generating function of the development process. Because of this, management does not want to spend money training developers to write secure code. Management does spend money on security technologies, but that’s usually after a successful attack! And at that point, it’s too late—the damage has been done. Fixing applications post-attack is expensive, both financially and in terms of your reputation.
Protecting property from theft and attack has been a time-proven practice. Our earliest ancestors had laws punishing those who chose to steal, damage, or trespass on property owned by citizens. Simply, people understand that certain chattels and property are private and should stay that way. The same ethics apply to the digital world, and therefore part of our job as developers is to create applications and solutions that protect digital assets.
You’ll notice that this book covers some of the fundamental issues that should be covered in school when designing and building secure systems is the subject. You might be thinking that designing is the realm of the architect or program manager, and it is, but as developers and testers you need to also understand the processes involved in outlining systems designed to withstand attack.
We know software will always have vulnerabilities, regardless of how much time and effort you spend trying to develop secure software, simply because you cannot predict future security research. We know this is true of Microsoft Windows .NET Server 2003, but we also know you can reduce the overall number of vulnerabilities and make it substantially harder to find and exploit vulnerabilities in your code by following the advice in this book.
If you design applications, or if you build, test, or document solutions, you need this book. If your applications are Web-based or Win32-based, you need this book. Finally, if you are currently learning or building Microsoft .NET Framework–based applications, you need this book. In short, if you are involved in building applications, you will find much to learn in this book.
Even if you’re writing code that doesn’t run on a Microsoft platform, much of the material in this book is still useful. Except for a few chapters that are entirely Microsoft-specific, the same types of problems tend to occur regardless of platform. Even when something might seem to be applicable only to Windows, it often has broader application. For example, an Everyone Full Control access control list and a file set to World Writable on a UNIX system are really the same problem, and cross-site scripting issues are universal.
The book is divided into five parts. Chapter 1 through Chapter 4 make up Part I, and outline the reasons why systems should be secured from attack and guidelines and analysis techniques for designing such systems.
The meat of the book is in Part II and Part III. Part II, encompassing Chapter 5 through Chapter 14, outlines critical coding techniques that apply to almost any application. Part III, includes four chapters (Chapter 15 through Chapter 18) that focus on networked applications and .NET code.
Part IV, includes six chapters (Chapter 19 through Chapter 24) that cover less-often-discussed subjects, such as testing, performing security code reviews, privacy, and secure software installation. Chapter 23 includes general guidelines that don’t fit in any single chapter.
Part V, includes five appendixes covering dangerous APIs, ridiculous excuses we’ve heard for not considering security, and security checklists for designers, developers and testers.
Unlike the authors of a good many other security books, we won’t just tell you how insecure applications are and moan about people not wanting to build secure systems. This book is utterly pragmatic and, again, relentlessly practical. It explains how systems can be attacked, mistakes that are often made, and, most important, how to build secure systems. (By the way, look for margin icons, which indicate security-related anecdotes.)
You can download the sample files from the book’s Companion Content page on the Web by connecting to http://www.microsoft.com/mspress/books/5957.asp. To access the sample files, click Companion Content in the More Information menu box on the right side of the page. This will load the Companion Content Web page, which includes a link for downloading the sample files and connecting to Microsoft Press Support. The download link opens an executable file containing a license agreement. To copy the sample files onto your hard disk, click the link to run the executable and then accept the license agreement that is presented. By default, the sample files will be copied to the My DocumentsMicrosoft PressSecureco2 folder. During the installation process, you’ll be given the option of changing that destination folder.
Most samples in this book are written in C or C++ and require Microsoft Visual Studio .NET, although most of the samples written in C/C++ work fine with most compilers, including Microsoft Visual C++ 6.0. The Perl examples have been tested using ActiveState Perl 5.6 or ActivateState Visual Perl 1.0 from http://www.activestate.com. Microsoft Visual Basic Scripting Edition and JScript code was tested with Windows Scripting Host included with Windows 2000 and later. All SQL examples were tested using Microsoft SQL Server 2000. Finally, Visual Basic .NET and Visual C# applications were written and tested using Visual Studio .NET.
All the applications but two in this book will run on computers running Windows 2000 that meet recommended operating system requirements. The Safer sample in Chapter 7 and the UTF8 MultiByteToWideChar sample in Chapter 11 require Windows XP or Windows .NET Server to run correctly. Compiling the code requires somewhat beefier machines that comply with the requirements of the compiler being used.
Every effort has been made to ensure the accuracy of this book and the com-panion content. Microsoft Press provides corrections for books through the World Wide Web at http://www.microsoft.com/mspress/support/. To connect directly to the Microsoft Press Knowledge Base and enter a query regarding a question or issue that you have, go to http://www.microsoft.com/mspress/support/search.asp.
When you look at the cover of this book, you see the names of only two authors, but this book would be nothing if we didn’t get help and input from numerous people. We pestered some people until they were sick of us, but still they were only too happy to help.
First, we’d like to thank the Microsoft Press folks, including Danielle Bird for agreeing to take on this second edition, Devon Musgrave for turning our "prose" into English and giving us grammar lessons, and Brian Johnson for making sure we were not lying. Much thanks also to Kerri DeVault for laying out the pages and Rob Nance for the part opener and other art.
Many people answered questions to help make this book as accurate as possible, including the following from Microsoft: Saji Abraham, Ümit Akku, Doug Bayer, Tina Bird, Mike Blaszczak, Grant Bolitho, Christopher Brumme, Neill Clift, David Cross, Scott Culp, Mike Danseglio, Bhavesh Doshi, Ramsey Dow, Werner Dreyer, Kedar Dubhashi, Patrick Dussud, Vadim Eydelman, Scott Field, Cyrus Gray, Brian Grunkemeyer, Caglar Gunyakti, Ron Jacobs, Jesper Johansson, Willis Johnson, Loren Kohnfelder, Sergey Kuzin, Mike Lai, Bruce Leban, Yung-Shin "Bala" Lin, Steve Lipner, Eric Lippert, Matt Lyons, Erik Olson, Dave Quick, Art Shelest, Daniel Sie, Frank Swiderski, Matt Thomlinson, Chris Walker, Landy Wang, Jonathan Wilkins, and Mark Zbikowski.
We also want to thank the entire Windows division for comments, nitpicks, and improvements—there are too many of you to list you individually!
Some people deserve special recognition because they provided copious material for this book, much of which was created during their respective products’ security pushes. Brandon Bray and Raymond Fowkes supplied much buffer overrun help and material. Dave Ross, Tom Gallagher, and Richie Lai are three of the foremost experts on Web-based security issues, especially the cross-site scripting material. John McConnell, Mohammed El-Gammal, and Julie Bennett created the core of the internationalization chapter and were a delight to work with. The secure .NET code chapter would be a skeleton if it were not for the help offered by Erik Olson and Ivan Medvedev; Ivan’s idea of "CAS in pictures" deserves special recognition. Adrian Oney and Peter Viscarola of Open Systems Resources, Inc. wrote the core of the device and kernel mode best practices at a moment’s notice. J.C. Cannon took it upon himself to write the privacy chapter. Finally, Ken Jones, Todd Stedl, David Wright, Richard Carey, and Everett McKay wrote vast amounts of material that led to the documentation chapter. The chapter on conducting security code reviews benefited from insightful feedback and references provided by Ramsey Dow and a PowerPoint presentation by Neill Clift. Vadim Eydelman provided a detailed analysis of the potential problems with using SO_EXCLUSIVEADDR and solutions that went into both this book and a Microsoft Knowledge Base article. Your eagerness to provide such rich and vast material is as humbling as it is encouraging.
The following people provided input for the first edition, and we’re still thankful for their help: Eli Allen, John Biccum, Thomas Deml, Monica Ene-Pietrosanu, Sean Finnegan, Tim Fleehart, Damian Haase, David Hubbard, Louis Lafreniere, Brian LaMacchia, John Lambert, Lawrence Landauer, Paul Leach, Terry Leeper, Rui Maximo, Daryl Pecelj, Jon Pincus, Rain Forest Puppy, Fritz Sands, Eric Schultze, Alex Stockton, Hank Voight, Richard Ward, Richard Waymire, and Mark Zhou.
Many outside Microsoft gave their time to help us with this book. We’d like to give our greatest thanks to Peter Gutmann (it’s an urban myth, Peter!), Steve Hayr of Accenture, Christopher W. Klaus of Internet Security Systems, John Pescatore of Gartner Inc., Herbert H. Thompson and James A. Whittaker of Florida Tech, and finally, Chris "Weld Pond" Wysopal of @Stake.
Most importantly, we want to thank everyone at Microsoft for taking up the Trusthworthy Computing rallying cry with such passion and urgency. We thank you all.