Writing Secure Code: Practical Strategies and Proven Techniques for Building Secure Applications in a Networked World

1363 Pages·2004·6.27 MB·English

by  Michael Howard

Copyright © 2003 by Microsoft Corporation
PUBLISHED BY
Microsoft Press
A Division of Microsoft Corporation One Microsoft Way
Redmond, Washington 98052-6399

Copyright © 2003 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.--2nd ed.
p. cm.
Includes index.
ISBN 0-7356-1722-8
1. Computer security. 2. Data encryption (Computer science). I. LeBlanc,
David, 1960-II. Title.

QA76.9.A25 H698 2002b
005.8--dc21
2002035986
Printed and bound in the United States of America.
1 2 3 4 5 6 7 8 9 QWT 8 7 6 5 4 3

Distributed in Canada by H.B. Fenn and Company Ltd.

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 [phone]. Visit our Web site at
www.microsoft.com/mspress. Send comments to [email protected].

Active Directory, ActiveX, Authenticode, Hotmail, JScript, Microsoft, Microsoft
Press, MSDN, MS-DOS, 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: Brian Johnson
Body Part No. X08-92500
For Cheryl and Blake, the two most beautiful people I know.
—Michael
To Jennifer, for putting up with still more lost weekends when we should have
been out riding together.
—David
Introduction
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
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.
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.
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.