Thông tin tài liệu
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
Ngày đăng: 25/03/2014, 12:14
Xem thêm: writing secure code, writing secure code