Copyright 2002 by Microsoft Corporation PUBLISHED BY Microsoft Press A Division of Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399 Copyright © 2002 by Microsoft Corporation All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher. Library of Congress Cataloging-in-Publication Data Howard, Michael, 1965– Writing Secure Code / Michael Howard, David LeBlanc. p. cm. ISBN 0-7356-1588-8 1. Computer security. 2. Data encryption (Computer science) I. LeBlanc, David, 1960– II. Title. QA76.9.A25 H698 2001 005.8 dc21 2001044546 Printed and bound in the United States of America. 1 2 3 4 5 6 7 8 9 QWE 6 5 4 3 2 Distributed in Canada by Penguin Books Canada Limited. A CIP catalogue record for this book is available from the British Library. Microsoft Press books are available through booksellers and distributors worldwide. For further information about international editions, contact your local Microsoft Corporation office or contact Microsoft Press International directly at fax (425) 706-7329. Visit our Web site at www.microsoft.com/mspress. Send comments to mspinput@microsoft.com. Active Directory, ActiveX, Authenticode, Hotmail, Jscript, Microsoft, Microsoft Press, MS-DOS, MSDN, Visual Basic, Visual C++, Visual Studio, Win32, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Acquisitions Editor: Danielle Bird Project Editor: Devon Musgrave Technical Editor: Julie Xiao Dedication To Blake, God߀™s little gift to Cheryl and me. To Cheryl, Blake could not ask for a more wonderful mother. ߀” Michael To Jennifer, for putting up with many lost weekends when we could have been out horseback riding. ߀”David In memory of all those people who needlessly perished on September 11, 2001. Foreword Improving security was a major focus while we were developing Windows 2000. At one point, we decided to run an unusual experiment to test the product߀™s mettle before we released it. We set up a Windows 2000 Web server called ߀?Windows2000test.com,߀• put it out there, and waited to see what happened. We made no announcement of any kind; we didn߀™t call any attention to it in any way whatsoever. Within a couple of hours, hundreds of people were already trying to hack it. Within days, tens of thousands of people were hammering away. These days, as soon as a product gets into their hands, hackers begin an intensive effort to find and exploit security holes. If the product developers don߀™t make an equally intensive effort to build security into their code, the hackers will almost surely succeed. A product߀™s security is every bit as important as its features. Don߀™t get me wrong߀”people would have no reason to buy a product without great features. But while developers know how to build features, they often don߀™t know how to design and build security. This book changes that. Writing Secure Code offers practical insights into secure design, secure coding, and testing techniques, many of which are not documented elsewhere. It will give you a richer understanding of what it takes to build secure applications. Michael and David are, respectively, members of the Secure Windows Initiative and the Trustworthy Computing Security Team at Microsoft. They have witnessed firsthand the sometimes basic coding mistakes that undermine product security, and their projects have helped us significantly improve how we designed and implemented security in products such as Windows 2000 and Windows XP. Their goal in writing this book is to pass on to you, the developer community, everything Microsoft has learned. Brian Valentine Senior Vice President, Windows Division Microsoft Corporation Acknowledgments 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 book, Devon Musgrave for turning ߀?Geek߀• into English and managing not to complain too much, and Julie Xiao for making sure we were not lying. Much thanks also to Elizabeth Hansford for laying out pages, Rob Nance for the part opener art, and Shawn Peck for copyediting. Many people answered questions to help make this book as accurate as possible, including the following from Microsoft: Saji Abraham, Eli Allen, John Biccum, Scott Culp, Thomas Deml, Monica Ene-Pietrosanu, Sean Finnegan, Tim Fleehart, Damian Haase, David Hubbard, Mike Lai, Louis Lafreniere, Brian LaMacchia, John Lambert, Lawrence Landauer, Paul Leach, Terry Leeper, Steve Lipner, Rui Maximo, Daryl Pecelj, Jon Pincus, Fritz Sands, Eric Schultze, Alex Stockton, Matt Thomlinson, Hank Voight, Chris Walker, Richard Ward, Richard Waymire, Mark Zbikowski, and Mark Zhou. We߀™d especially like to thank the following ߀™softies: Russ Wolfe, who explained numerous Unicode and UTF-8 issues and wouldn߀™t shut up until we had the issues documented adequately. Kamen Moutafov, a genuinely nice guy, who spent numerous hours helping with the RPC section. He߀™s one of those developers who answers stupid questions without making you feel dumb. Erik Olsen went to great lengths to make sure the .NET issues were nailed down. If it weren߀™t for Erik, Chapter 13 would be tiny. Eric Jarvi read most all the chapters and helped immensely by offering numerous improvements, most of which started with, ߀?You really should explain߀¦ß€• We want to point out that Kamen, Erik, and Eric rock. They diligently reviewed material while they were in the final stages of shipping their respective products: Windows XP, the .NET Framework, and Visual Studio .NET. It would have been easy for them to say, ߀?I߀™m busy, leave me alone,߀• but they didn߀™t. They could see that some short-term time spent getting this book right would have long-term benefits for themselves (as they won߀™t have to answer the same questions time and again), for Microsoft, and, most important, for our shared and valued customers. Many outside Microsoft gave their time to help us with this book. We߀™d like to give our greatest thanks to Rain Forest Puppy for providing first-rate Web security comments. By the way, Mr. Puppy, no offense taken! John Pescatore of Gartner Inc. for his insightful (and blunt) comments, which helped shape the early chapters. Professor Jesper Johansson of Boston University, who read every word, sentence, paragraph, and chapter of the book and had comments on every word, sentence, paragraph, and chapter of the book! Leslee LaFountain of the NSA for showing such great interest in this book. And, finally, the Secure Windows Initiative team. We thank you all. Introduction This is a book both of us have wanted to write for a long time. We߀™re both involved in convincing and teaching people how to make their applications secure from attack, and until recently few people have cared about secure systems. Don߀™t get us wrong: some people truly do want to ship great products, and by great, we also mean secure. One of us߀”Michael߀”remembers writing his first program in Microsoft Windows in 1984. It was a simple program, not dissimilar to the canonical ߀?Hello, World߀• program defined in Kernighan and Ritchie߀™s classic book The C Programming Language (Prentice Hall PTR, 1988, second edition). He was so excited when the application compiled, linked, and ran for the first time, and we߀™re sure that any of you who worked on the early versions of Windows will remember how difficult it was to create Windows applications back then. The Windows SDK and Microsoft C compiler combination was not an easy one to learn, especially if you came from a text-based background such as MS-DOS, PC-DOS, or UNIX. Looking back at that first application in 1984, we both have considered whether it was secure from attack. And the simple answer is, yes, it was. It was secure simply because no one hooked Windows 1.x߀“based computers to any kind of network, let alone the Internet. It was also secure because cybercrime and Internet-based vandalism wasn߀™t a rampant problem in 1984. How times have changed! Today߀™s Internet environment is incredibly hostile, and all applications must be designed with this in mind. If the PC running Windows 1.x were hooked to the Internet today, the application would certainly be attacked. It was never designed to run in such a hostile environment. To be honest, the application was not designed with security in mind whatsoever because Michael knew next to nothing about secure coding back then. Few of us did, and those few certainly did not to the same extent that many people understand secure code today. By secure code, 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. Teaching you to design, write, and test application code in a secure manner is the sole purpose of this book. 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 go elsewhere and take their patronage and money with them. 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. Both of us are excited to have written this book because it߀™s based on the real-world experience we߀™ve gained convincing Microsoft development teams, external partners, and clients that they need to build secure applications or suffer the horrible consequences. Who Should Read 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. Organization of This Book The book is divided into five parts. Chapter 1, ߀?The Need for Secure Systems,߀• and Chapter 2, ߀?Designing Secure Systems,߀• make up Part I, ߀?Contemporary Security,߀• and outline the reasons why systems should be secured from attack and the guidelines and analysis techniques for designing such systems. The meat of the book is in Parts II and III. Part II, ߀?Secure Coding Techniques,߀• encompassing Chapters 3 through 8, outlines critical coding techniques that apply to almost any application. Part III, ߀?Network-Based Application Considerations,߀• includes four chapters (Chapters 9 through 12) that focus on networked applications, including Web-based applications. Part IV, ߀?Special Topics,߀• includes three chapters (Chapters 13 through 15) that cover less-often-discussed subjects, including security in .NET applications, testing, and secure software installation. Chapter 16 includes general guidelines that don߀™t fit in any single chapter. Part V, ߀?Appendixes,߀• includes four appendixes covering sundry other matters, including dangerous APIs and the lame excuses we߀™ve heard for not considering security! Michael wrote Chapters 1, 2, 4߀“8, and 12߀“14. David wrote Chapters 3, 9, 11, and 15. Both authors crafted Chapters 10 and 16. As a final note, 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. About the Companion CD The CD included with this book contains all sample programs discussed in the book, a fully searchable electronic version of the book, as well as helpful tools. See the Readme.txt file on the CD for information on using these tools. To view the contents of the CD, insert the CD into your CD-ROM drive. If the startup application does not begin automatically, run StartCD.exe in the root directory of the CD. Installing the Sample Files You can view the sample files from the companion CD, or you can install them on your hard disk and use them to create your own applications. Installing the sample files requires approximately 1.4 MB of disk space. If you have trouble running any of these files, refer to the Readme.txt file in the root directory of the companion CD or to the text in the book that describes these programs. Tools Two tools have been provided on this CD: the Token Master and the PPCKey tool. The supporting documentation for the PPCKey tool is also available on the CD. See the Readme.html file included in the Tools\PPCKey folder for information about this tool. eBook This CD contains an electronic version of the book. This eBook allows you to view the book text on screen and to search the contents. For information on installing and using the eBook, see the Readme.txt file in the \eBook folder. [...]... as yet undefined, setting Assume instead that your code will run in the most hostile of environments, and design, write, and test your code accordingly It߀™s also important to remember that secure systems are quality systems Code designed and built with security as a prime feature is more robust than code written with security as an afterthought Secure products are also more immune to media criticism,... developers finding the vulnerable code • The cost of developers fixing the code • The cost of testers testing the fix • The cost of testing the setup of the fix • The cost of creating and testing international versions • The cost of digitally signing the fix if you support signed code, such as Authenticode • The cost to post the fix to your Web site • The cost of writing the supporting documentation... goals • Consider security as a product feature • Learn from mistakes • Use least privilege • Use defense in depth • Assume external systems are insecure • Plan on failure • Fail to a secure mode • Employ secure defaults • Remember that security features != secure features • Never depend on security through obscurity Numerous other ߀?bumper sticker߀• words of wisdom could be included in this list,... deploying, and fixing systems in a secure manner, you will find you spend an inordinate amount of time on the last aspect of the process: fixing security bugs Establishing a process is important because secure systems encompass a security process as well as the product itself You cannot have a secure product without a security process Issues to consider include how secure systems are designed, developed,... for running with least privilege is quite simple If a security vulnerability is found in the code and an attacker can inject code into your process (or run a Trojan horse or virus), the malicious code will run with the same privileges as the process If the process is running as an administrator, the malicious code runs as an administrator This is why we recommend people do not run as a member of the... a review of your product that discusses the security weakness in the code you just wrote Even worse is reading about a serious security vulnerability in the code you wrote! The following sections describe some methods for creating an atmosphere in your organization in which people care about, and excel at, designing and building secure applications Get the Boss to Send an E-Mail Assuming you߀™ve succeeded... isolated in a certain area of the code Like performance, scalability, manageability, and code readability, security awareness is a discipline that every software designer, developer, and tester has to know about After working with various development organizations, we߀™ve found that if you keep the following design security principles sacrosanct, you can indeed build secure systems: • Establish a security... priority߀• needs to be a corporate dictum because, as we߀™ve seen, the need to ship secure software is greater than ever Your users demand that you build secure applications߀”they see such systems as a right, not a privilege Also, your competitor߀™s sales force will whisper to your potential customers that your code is risky and unsafe So where do you begin instilling security in your organization?... perfect security (As is often said in the security community, the most secure system is the one that߀™s turned off and buried in a concrete bunker, but even that is not perfect security.) We߀™re talking about software secure enough and good enough for the environment in which it will operate For example, you should make a multiplayer game secure from attack, but you should spend even more time beefing up... are better off not getting into this situation in the first place, and that means designing secure applications that are intended to withstand attack The argument I߀™ve just made is selfish I߀™ve looked at reasons to build secure systems from the software developer߀™s perspective Failure to build systems securely leads to more work for you in the long run and a bad reputation, which in turn can . about secure coding back then. Few of us did, and those few certainly did not to the same extent that many people understand secure code today. By secure code, we don߀™t mean security code or code. features. We mean code that is designed to withstand attack by malicious attackers. Secure code is also robust code. Teaching you to design, write, and test application code in a secure manner. know how to design and build security. This book changes that. Writing Secure Code offers practical insights into secure design, secure coding, and testing techniques, many of which are not documented