Practically every day, we read about a new type of attack on computer systems and networks. Viruses, worms, denials of service, and password sniffers are attacking all types of systems -- from banks to major e-commerce sites to seemingly impregnable government and military computers --at an alarming rate.Despite their myriad manifestations and different targets, nearly all attacks 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, by Mark G. Graff and Ken vanWyk, 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. Writing secure code isn't easy, and there are no quick fixes to bad code. To build code that repels attack, readers need to be vigilant through each stage of the entire code lifecycle:
- Architecture: during this stage, applying security principles such as "least privilege" will help limit even the impact of successful attempts to subvert software.
- Design: during this stage, designers must determine how programs will behave when confronted with fatally flawed input data. The book also offers advice about performing security retrofitting when you don't have the source code -- ways of protecting software from being exploited even if bugs can't be fixed.
- Implementation: during this stage, programmers must sanitize all program input (the character streams representing a programs' entire interface with its environment -- not just the command lines and environment variables that are the focus of most securityanalysis).
- Testing: during this stage, programs must be checked using both static code checkers and runtime testing methods -- for example, the fault injection systems now available to check for the presence of such flaws as buffer overflow.
- Operations: during this stage, patch updates must be installed in a timely fashion. In early 2003, sites that had diligently applied Microsoft SQL Server updates were spared the impact of the Slammer worm that did serious damage to thousands of systems.
Beyond the technical,
Secure Coding sheds new light on the economic, psychological, and sheer practical reasons why security vulnerabilities are so ubiquitous today. It presents a new way of thinking about these vulnerabilities and ways that developers can compensate for the factors that have produced such unsecured software in the past. It issues a challenge to all those concerned about computer security to finally make a commitment to building code the right way.
Dedication; Preface; Objectives of This Book; Structure of This Book; What This Book Does Not Cover; Conventions Used in This Book; About the Examples; Comments and Questions; Acknowledgments; Chapter 1: No Straight Thing; 1.1 The Vulnerability Cycle; 1.2 What Is an Attack?; 1.3 Why Good People Write Bad Code; 1.4 A Call to Arms; 1.5 Summary; Chapter 2: Architecture; 2.1 What Is Security Architecture?; 2.2 Principles of Security Architecture; 2.3 Case Study: The Java Sandbox; 2.4 Summary; Chapter 3: Design; 3.1 Why Does Good Design Matter?; 3.2 Secure Design Steps; 3.3 Special Design Issues; 3.4 Bad Practices; 3.5 Case Studies; 3.6 Summary; Chapter 4: Implementation; 4.1 Good Practices; 4.2 Bad Practices; 4.3 Case Studies; 4.4 Summary; Chapter 5: Operations; 5.1 Security Is Everybody's Problem; 5.2 Good Practices; 5.3 Bad Practices; 5.4 Case Studies; 5.5 Summary; Chapter 6: Automation and Testing; 6.1 Why Test?; 6.2 Good General Practices; 6.3 Good Practices Through the Lifecycle; 6.4 Risk Assessment Methodologies; 6.5 Case Studies; 6.6 Summary; Appendix A: Resources; A.1 Books; A.2 Papers and Articles; A.3 Web Sites and Online Resources; A.4 A Final Note on Resources; Colophon;
