Secure Coding: Principles Practices

 
   
  Table of Contents
  Index
  Reviews
  Reader Reviews
  Errata
Secure Coding: Principles & Practices
By Mark G.  Graff, Kenneth R.  van Wyk
 
Publisher : O'Reilly
Pub Date : June 2003
ISBN : 0-596-00242-4
Pages : 224
Slots : 1    


Despite their myriad manifestations and different targets, nearly all attacks on computer systems have one fundamental cause: the code used to run far too many systems today is not secure. Flaws in its design, implementation, testing, and operations allow attackers all-too-easy access. Secure Coding: Principles & Practices looks at the problem of bad code in a new way. Packed with advice based on the authors' decades of experience in the computer security field, this concise and highly readable book explains why so much code today is filled with vulnerabilities, and tells readers what they must do to avoid writing code that can be exploited by attackers.

 
   

Dedication

We dedicate this work to our late friend, Jim Ellis. The world knew him as James T. Ellis (or jte@cert.org), coinventor of Usenet and one of the early members of the team at CERT/CC. He taught each of us a lot about secure coding, too.

Working off the karmic debt we owe to this generous genius is one of our main motivations for writing this book.

Mark G. Graff and Kenneth R. van Wyk

   
   

Copyright 2003 O'Reilly & Associates, Inc.

Printed in the United States of America.

Published by O'Reilly & Associates, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O'Reilly & Associates books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://safari.oreilly.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com.

Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered trademarks of O'Reilly & Associates, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O'Reilly & Associates, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. The association between the image of a bridge and the topic of secure coding is a trademark of O'Reilly & Associates, Inc.

While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

   
   

Preface

Learn all you can from the mistakes of others. You won't have time to make them all yourself.

Alfred P. Sheinwold, Author of Five Weeks to Winning Bridge

What's so hard about writing secure code? These days, we consumers get a few dozen security patch notices per week from the world's software product vendors and watchdog teams such as the Computer Emergency Response Team Coordination Center (CERT/CC) at Carnegie Mellon University. Terms such as buffer overflow and race condition foam out of the bulletins like poisonous vapors. Explore those terms a bit, and you'll find whole categories of mistakes that are possible to makeeasy, in factwhile developing a piece of software.

In this book, we take you on a virtual tour through the software development process, from inception to deployment. We focus on four broad stagesinitial architecture, detailed design, implementation ("coding"), and operationand discuss the security issues a developer faces at each stage. We also explore, of course, many of the specific software flaws we've studied and cataloged during our careers.

We present expert technical advice, too, based on our decades of hands-on experience and tempered by some of our more notable failures. And while we invite you to learn from our mistakes, we also invite you to think with usthink hard about why security vulnerabilities exist to begin with and why they seem impossible to stamp out. In this book, we try to shed new light on the variety of reasons we can see. And we explain in detail how developers, compensating for these factors with appropriate techniques and processes, can produce software "just secure enough" for the needs of their enterprises , users, and customers.