Secure Programming with Static Analysis / Edition 1

Other Format (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $15.91
Usually ships in 1-2 business days
(Save 73%)
Other sellers (Other Format)
  • All (12) from $15.91   
  • New (6) from $43.51   
  • Used (6) from $15.91   

Overview

The First Expert Guide to Static Analysis for Software Security!

Creating secure code requires more than just good intentions. Programmers need to know that their code will be safe in an almost infinite number of scenarios and configurations. Static source code analysis gives users the ability to review their work with a fine-toothed comb and uncover the kinds of errors that lead directly to security vulnerabilities. Now, there’s a complete guide to static analysis: how it works, how to integrate it into the software development processes, and how to make the most of it during security code review. Static analysis experts Brian Chess and Jacob West look at the most common types of security defects that occur today. They illustrate main points using Java and C code examples taken from real-world security incidents, showing how coding errors are exploited, how they could have been prevented, and how static analysis can rapidly uncover similar mistakes. This book is for everyone concerned with building more secure software: developers, security engineers, analysts, and testers.

Coverage includes:

Why conventional bug-catching often misses security problems

How static analysis can help programmers get security right

The critical attributes and algorithms that make or break a static analysis tool

36 techniques for making static analysis more effective on your code

More than 70 types of serious security vulnerabilities, with specific solutions

Example vulnerabilities from Firefox, OpenSSH, MySpace, eTrade, Apache httpd, and many more

Techniques for handling untrusted input

Eliminating buffer overflows: tactical and strategic approaches

Avoiding errors specific to Web applications, Web services, and Ajax

Security-aware logging, debugging, and error/exception handling

Creating, maintaining, and sharing secrets and confidential information

Detailed tutorials that walk you through the static analysis process

“We designed Java so that it could be analyzed statically. This book shows you how to apply advanced static analysis techniques to create more secure, more reliable software.”

Bill Joy, Co-founder of Sun Microsystems, co-inventor of the Java programming language

“'Secure Programming with Static Analysis' is a great primer on static analysis for security-minded developers and security practitioners. Well-written, easy to read, tells you what you need to know.”

David Wagner, Associate Professor, University of California Berkeley

“Software developers are the first and best line of defense for the security of their code. This book gives them the security development knowledge and the tools they need in order to eliminate vulnerabilities before they move into the final products that can be exploited.”

Howard A. Schmidt, Former White House Cyber Security Advisor

BRIAN CHESS is Founder and Chief Scientist of Fortify Software, where his research focuses on practical methods for creating secure systems. He holds a Ph.D. in Computer Engineering from University of California Santa Cruz, where he studied the application of static analysis to finding security-related code defects.

JACOB WEST manages Fortify Software’s Security Research Group, which is responsible for building security knowledge into Fortify’s products. He brings expertise in numerous programming languages, frameworks, and styles together with deep knowledge about how real-world systems fail.

CD contains a working demonstration version of Fortify Software’s Source Code Analysis (SCA) product; extensive Java and C code samples; and the tutorial chapters from the book in PDF format.

Part I: Software Security and Static Analysis 1

1 The Software Security Problem 3

2 Introduction to Static Analysis 21

3 Static Analysis as Part of the Code Review Process 47

4 Static Analysis Internals 71

Part II: Pervasive Problems 115

5 Handling Input 117

6 Buffer Overflow 175

7 Bride of Buffer Overflow 235

8 Errors and Exceptions 265

Part III: Features and Flavors 295

9 Web Applications 297

10 XML and Web Services 349

11 Privacy and Secrets 379

12 Privileged Programs 421

Part IV: Static Analysis in Practice 457

13 Source Code Analysis Exercises for Java 459

14 Source Code Analysis Exercises for C 503

Epilogue 541

References 545

Index 559

Read More Show Less

Product Details

  • ISBN-13: 9780321424778
  • Publisher: Addison-Wesley
  • Publication date: 6/28/2007
  • Series: Addison-Wesley Software Security Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 587
  • Sales rank: 824,866
  • Product dimensions: 6.96 (w) x 9.18 (h) x 1.24 (d)

Meet the Author

B rian Chess is a founder of Fortify Software. He currently serves as Fortify’s Chief Scientist, where his work focuses on practical methods for creating secure systems. Brian holds a Ph.D. in Computer Engineering from the University of California at Santa Cruz, where he studied the application of static analysis to the problem of finding security-relevant defects in source code. Before settling on security, Brian spent a decade in Silicon Valley working at huge companies and small startups. He has done research on a broad set of topics, ranging from integrated circuit design all the way to delivering software as a service. He lives in Mountain View, California.

J acob West manages Fortify Software’s Security Research Group, which is responsible for building security knowledge into Fortify’s products. Jacob brings expertise in numerous programming languages, frameworks, and styles together with knowledge about how real-world systems can fail. Before joining Fortify, Jacob worked with Professor David Wagner at the

University of California at Berkeley to develop MOPS (MOdel Checking Programs for Security properties), a static analysis tool used to discover security vulnerabilities in C programs. When he is away from the keyboard, Jacob spends time speaking at conferences and working with customers to advance their understanding of software security. He lives in San Francisco, California.

Read More Show Less

Read an Excerpt

PrefacePreface

Following the light of the sun, we left the Old World. —Christopher Columbus

We live in a time of unprecedented economic growth, increasingly fueled by computer and communications technology. We use software to automate factories, streamline commerce, and put information into the hands of people who can act upon it. We live in the information age, and software is the primary means by which we tame information.

But oddly enough, much of the activity that takes place under the guise of computer security isn't really about solving security problems at all; it's about cleaning up the mess that security problems create. Virus scanners, firewalls, patch management, and intrusion-detection systems are all means by which we make up for shortcomings in software security. The software industry puts more effort into compensating for bad security than it puts into creating secure software in the first place. Do not take this to mean that we see no value in mechanisms that compensate for security failures. Just as every ship should have lifeboats, it is both good and healthy that our industry creates ways to quickly compensate for a newly discovered vulnerability. But the state of software security is poor. New vulnerabilities are discovered every day. In a sense, we've come to expect that we will need to use the lifeboats every time the ship sails.

Changing the state of software security requires changing the way software is built. This is not an easy task. After all, there are a limitless number of security mistakes that programmers could make! The potential for error might be limitless, but in practice, the programming community tends to repeat the same security mistakes. Almost two decades of buffer overflow vulnerabilities serve as an excellent illustration of this point. In 1988, the Morris worm made the Internet programming community aware that a buffer overflow could lead to a security breach, but as recently as 2005, buffer overflow was the number one cause of security problems cataloged by the Common Vulnerabilities and Exposures (CVE) Project CWE, 2006. This significant repetition of well-known mistakes suggests that many of the security problems we encounter today are preventable and that the software community possesses the experience necessary to avoid them.

We are thrilled to be building software at the beginning of the twenty-first century. It must have felt this way to be building ships during the age of exploration. When Columbus came to America, exploration was the driving force behind economic expansion, and ships were the means by which explorers traveled the world. In Columbus's day, being a world economic power required being a naval power because discovering a new land didn't pay off until ships could safely travel the new trade routes. Software security has a similar role to play in today's world. To make information technology pay off, people must trust the computer systems they use. Some pundits warn about an impending "cyber Armageddon," but we don't fear an electronic apocalypse nearly so much as we see software security as one of the primary factors that control the amount of trust people are willing to place in technology. Without adequate security, we cannot realize the full potential of the digital age.

We believe that it is the responsibility of the people who create software to make sure that their creations are secure. Software security cannot be left to the system administrator or the end user. Network security, judicious administration, and wise use are all important, but in the long run, these endeavors cannot succeed if the software is inherently vulnerable. Although security can sometimes appear to be a black art or a matter of luck, we hope to show that it is neither. Making security sound impossible or mysterious is giving it more than its due. Given the right knowledge and the right tools, good software security can be achieved by building security in to the software-development process.

We sometimes encounter programmers who question whether software security is a worthy goal. After all, if no one hacked your software yesterday, why would you believe they'll hack it tomorrow? Security requires expending some extra thought, attention, and effort. This extra work wasn't nearly so important in previous decades, and programmers who haven't yet suffered security problems use their good fortune to justify continuing to ignore security. In his investigation of the loss of the space shuttle Challenger, Richard Feynman found that NASA had based its risk assessment on the fact that previous shuttle missions had been successful Feynman, 1986. They knew anomalous behavior had taken place in the past, but they used the fact that no disaster had occurred yet as a reason to believe that no disaster would ever occur. The resulting erosion of safety margins made failure almost inevitable. Feynman writes, "When playing Russian roulette, the fact that the first shot got off safely is little comfort for the next."

Security Matters: Improving Software Security with Static Source Code Analysis

Two threads are woven throughout the book: software security and static source code analysis. We discuss a wide variety of common coding errors that lead to security problems, explain the security ramifications of each, and give advice for charting a safe course. Our most common piece of advice eventually found its way into the title of the book: Use static analysis tools to identify coding errors before they can be exploited. Our focus is on commercial software for both businesses and consumers, but our emphasis is on business systems. We won't get into the details that are critical for building software for functions that imply special security needs. A lot could be said about the specific security requirements for building an operating system or an electronic voting machine, but we encounter many more programmers who need to know how to build a secure Web site or enterprise application.

Above all else, we hope to offer practical and immediately practicable advice for avoiding software security pitfalls. We use dozens of real-world examples of vulnerable code to illustrate the pitfalls we discuss, and the book includes a static source code analysis tool on a companion CD so that readers can experiment with the detection techniques we describe.

The book is not a guide to using security features, frameworks, or APIs. We do not discuss the Java Security Manager, advanced cryptographic techniques, or the right approach to identity management. Clearly, these are important topics. They are so important, in fact, that they warrant books of their own. Our goal is to focus on things unrelated to security features that put security at risk when they go wrong.

In many cases, the devil is in the details. Security principles (and violations of security principles) have to be mapped to their manifestation in source code. We've chosen to focus on programs written in C, C++, and Java because they are the languages we most frequently encounter today. We see plenty of other languages, too. Security-sensitive work is being done in C#, Visual Basic, PHP, Perl, Python, Ruby, and COBOL, but it would be difficult to write a single book that could even scratch the surface with all these languages.

In any case, many of the problems we discuss are language independent, and we hope that you will be able to look beyond the syntax of the examples to understand the ramifications for the languages you use.

Who Should Read the Book

This book is written for people who have decided to make software security a priority. We hope that programmers, managers, and software architects will all benefit from reading it. Although we do not assume any detailed knowledge about software security or static analysis, we cover the subject matter in enough depth that we hope professional code reviewers and penetration testers will benefit, too. We do assume that you are comfortable programming in either C or Java, and that you won't be too uncomfortable reading short examples in either language. Some chapters are slanted more toward one language than another. For instance, the examples in the chapters on buffer overflow are written in C.

Our hope is that by giving a lot of examples of vulnerable code, we can help you do a better job of identifying potential problems in your own code.

How the Book Is Organized

The book is divided into four parts. Part I, "Software Security and Static Analysis," describes the big picture: the software security problem, the way static analysis can help, and options for integrating static analysis as part of the software-development process. Part II, "Pervasive Problems," looks at pervasive security problems that can impact software, regardless of its functionality, while Part III, "Features and Flavors," tackles security concerns that affect common flavors of programs and specific software features. Part IV, "Static Analysis in Practice," brings together Parts I, II, and III with a set of hands-on exercises that show how static analysis can improve software security.

Chapter 1, "The Software Security Problem," outlines the software security dilemma from a programmer's perspective: why security is easy to get wrong and why typical methods for catching bugs aren't very effective when it comes to finding security problems.

Chapter 2, "Static Analysis," introduces static source code analysis. It looks at the variety of problems that static analysis can solve, including structure, quality, and, of course, security. We take a quick tour of open-source and commercial static analysis tools.

Chapter 3, "Static Analysis as Part of Code Review," looks at how static analysis tools can be put to work as part of a security review process. We examine the organizational decisions that are essential to making effective use of the tools. We also look at metrics based on static analysis output.

Chapter 4, "Handling Input," takes an in-depth look at how static analysis tools work. We explore the essential components involved in building a tool and consider the trade-offs that tools make to achieve good precision and still scale to analyze millions of lines of code.

Part II outlines security problems that are pervasive in software. Throughout the chapters in this section and the next, we give positive guidance for secure programming and then use specific code examples (many of them from real programs) to illustrate pitfalls to be avoided. Along the way, we point out places where static analysis can help.

Chapter 5, "Handling Input," addresses the most thorny software security topic that programmers have faced in the past, and the one they are most likely to face in the future: handling the many forms and flavors of untrustworthy input.

Chapter 6, "Buffer Overflow I," and Chapter 7, "Bride of Buffer Overflow," look at a specific input-driven software security problem that has been with us for decades: buffer overflow. Chapter 6 begins with a tactical approach: how to spot the specific coding techniques that are most likely to lead to an exploitable buffer overflow. Chapter 7 steps back and examines some of the indirect causes of buffer overflow, such as attacker-controlled format strings and integer wraparound. We then step back and take a more strategic look at buffer overflow and possible ways that the problem can be tamed.

Chapter 8, "Errors and Exceptions," addresses the way programmers think about errors and exceptions. Although errors and exceptions are only rarely the direct cause of security vulnerabilities, they are often related to vulnerabilities in an indirect manner. The connection between unexpected conditions and security problems is so strong that error handling and recovery will always be a security topic. At the end, the chapter discusses general approaches to logging and debugging, which is often integrally connected with error-handling code.

Part III uses the same positive guidance and specific code examples to tackle security concerns found in common flavors of programs and related to specific software features.

Chapter 9, "Web Applications," looks at the most popular security topic of the day: the World Wide Web. We look at security problems that are specific to the Web and to the HTTP protocol.

Chapter 10, "

Although security features are not our primary focus, some security features are so error prone that they deserve special treatment. Chapter 11, "Privacy and Secrets," looks at programs that need to protect private information and, more generally, the need to maintain secrets. Chapter 12, "Privileged Programs," looks at the special security requirements that must be taken into account when writing a program that operates with a different set of privileges than the user who invokes it.

Part IV is about gaining practical experience with static analysis. This book's companion CD includes a static analysis tool, courtesy of our company, Fortify Software, and source code for a number of sample projects. Chapter 13, "Source Code Analysis Exercises for Java," is a tutorial that covers static analysis from a Java perspective; Chapter 14, "Source Code Analysis Exercises for C and C++," does the same thing, but with examples and exercises written in C.

Conventions Used in the Book

Discussing security errors makes it easy to slip into a negative state of mind or to take a pessimistic outlook. We try to stay positive by focusing on what needs to be done to get security right. Specifics are important, though, so when we discuss programming errors, we try to give a working example that demonstrates the programming mistake under scrutiny. When the solution to a particular problem is far removed from our original example, we also include a rewritten version that corrects the problem. To keep the examples straight, we use one icon to denote code that intentionally contains a weakness:

We use a different icon to denote code where the weakness has been corrected:

Other conventions used in the book include a monospaced font for code, both in the text and in examples.

© Copyright Pearson Education. All rights reserved.

Read More Show Less

Table of Contents

Part I: Software Security and Static Analysis 1

1 The Software Security Problem 3

2 Introduction to Static Analysis 21

3 Static Analysis as Part of the Code Review Process 47

4 Static Analysis Internals 71

Part II: Pervasive Problems 115

5 Handling Input 117

6 Buffer Overflow 175

7 Bride of Buffer Overflow 235

8 Errors and Exceptions 265

Part III: Features and Flavors 295

9 Web Applications 297

10 XML and Web Services 349

11 Privacy and Secrets 379

12 Privileged Programs 421

Part IV: Static Analysis in Practice 457

13 Source Code Analysis Exercises for Java 459

14 Source Code Analysis Exercises for C 503

Epilogue 541

References 545

Index 559

Read More Show Less

Preface

Preface

Following the light of the sun, we left the Old World. —Christopher Columbus

We live in a time of unprecedented economic growth, increasingly fueled by computer and communications technology. We use software to automate factories, streamline commerce, and put information into the hands of people who can act upon it. We live in the information age, and software is the primary means by which we tame information.

But oddly enough, much of the activity that takes place under the guise of computer security isn't really about solving security problems at all; it's about cleaning up the mess that security problems create. Virus scanners, firewalls, patch management, and intrusion-detection systems are all means by which we make up for shortcomings in software security. The software industry puts more effort into compensating for bad security than it puts into creating secure software in the first place. Do not take this to mean that we see no value in mechanisms that compensate for security failures. Just as every ship should have lifeboats, it is both good and healthy that our industry creates ways to quickly compensate for a newly discovered vulnerability. But the state of software security is poor. New vulnerabilities are discovered every day. In a sense, we've come to expect that we will need to use the lifeboats every time the ship sails.

Changing the state of software security requires changing the way software is built. This is not an easy task. After all, there are a limitless number of security mistakes that programmers could make! The potential for error might be limitless, but in practice, the programming community tends to repeat the same security mistakes. Almost two decades of buffer overflow vulnerabilities serve as an excellent illustration of this point. In 1988, the Morris worm made the Internet programming community aware that a buffer overflow could lead to a security breach, but as recently as 2005, buffer overflow was the number one cause of security problems cataloged by the Common Vulnerabilities and Exposures (CVE) Project CWE, 2006. This significant repetition of well-known mistakes suggests that many of the security problems we encounter today are preventable and that the software community possesses the experience necessary to avoid them.

We are thrilled to be building software at the beginning of the twenty-first century. It must have felt this way to be building ships during the age of exploration. When Columbus came to America, exploration was the driving force behind economic expansion, and ships were the means by which explorers traveled the world. In Columbus's day, being a world economic power required being a naval power because discovering a new land didn't pay off until ships could safely travel the new trade routes. Software security has a similar role to play in today's world. To make information technology pay off, people must trust the computer systems they use. Some pundits warn about an impending "cyber Armageddon," but we don't fear an electronic apocalypse nearly so much as we see software security as one of the primary factors that control the amount of trust people are willing to place in technology. Without adequate security, we cannot realize the full potential of the digital age.

We believe that it is the responsibility of the people who create software to make sure that their creations are secure. Software security cannot be left to the system administrator or the end user. Network security, judicious administration, and wise use are all important, but in the long run, these endeavors cannot succeed if the software is inherently vulnerable. Although security can sometimes appear to be a black art or a matter of luck, we hope to show that it is neither. Making security sound impossible or mysterious is giving it more than its due. Given the right knowledge and the right tools, good software security can be achieved by building security in to the software-development process.

We sometimes encounter programmers who question whether software security is a worthy goal. After all, if no one hacked your software yesterday, why would you believe they'll hack it tomorrow? Security requires expending some extra thought, attention, and effort. This extra work wasn't nearly so important in previous decades, and programmers who haven't yet suffered security problems use their good fortune to justify continuing to ignore security. In his investigation of the loss of the space shuttle Challenger, Richard Feynman found that NASA had based its risk assessment on the fact that previous shuttle missions had been successful Feynman, 1986. They knew anomalous behavior had taken place in the past, but they used the fact that no disaster had occurred yet as a reason to believe that no disaster would ever occur. The resulting erosion of safety margins made failure almost inevitable. Feynman writes, "When playing Russian roulette, the fact that the first shot got off safely is little comfort for the next."

Security Matters: Improving Software Security with Static Source Code Analysis

Two threads are woven throughout the book: software security and static source code analysis. We discuss a wide variety of common coding errors that lead to security problems, explain the security ramifications of each, and give advice for charting a safe course. Our most common piece of advice eventually found its way into the title of the book: Use static analysis tools to identify coding errors before they can be exploited. Our focus is on commercial software for both businesses and consumers, but our emphasis is on business systems. We won't get into the details that are critical for building software for functions that imply special security needs. A lot could be said about the specific security requirements for building an operating system or an electronic voting machine, but we encounter many more programmers who need to know how to build a secure Web site or enterprise application.

Above all else, we hope to offer practical and immediately practicable advice for avoiding software security pitfalls. We use dozens of real-world examples of vulnerable code to illustrate the pitfalls we discuss, and the book includes a static source code analysis tool on a companion CD so that readers can experiment with the detection techniques we describe.

The book is not a guide to using security features, frameworks, or APIs. We do not discuss the Java Security Manager, advanced cryptographic techniques, or the right approach to identity management. Clearly, these are important topics. They are so important, in fact, that they warrant books of their own. Our goal is to focus on things unrelated to security features that put security at risk when they go wrong.

In many cases, the devil is in the details. Security principles (and violations of security principles) have to be mapped to their manifestation in source code. We've chosen to focus on programs written in C, C++, and Java because they are the languages we most frequently encounter today. We see plenty of other languages, too. Security-sensitive work is being done in C#, Visual Basic, PHP, Perl, Python, Ruby, and COBOL, but it would be difficult to write a single book that could even scratch the surface with all these languages.

In any case, many of the problems we discuss are language independent, and we hope that you will be able to look beyond the syntax of the examples to understand the ramifications for the languages you use.

Who Should Read the Book

This book is written for people who have decided to make software security a priority. We hope that programmers, managers, and software architects will all benefit from reading it. Although we do not assume any detailed knowledge about software security or static analysis, we cover the subject matter in enough depth that we hope professional code reviewers and penetration testers will benefit, too. We do assume that you are comfortable programming in either C or Java, and that you won't be too uncomfortable reading short examples in either language. Some chapters are slanted more toward one language than another. For instance, the examples in the chapters on buffer overflow are written in C.

Our hope is that by giving a lot of examples of vulnerable code, we can help you do a better job of identifying potential problems in your own code.

How the Book Is Organized

The book is divided into four parts. Part I, "Software Security and Static Analysis," describes the big picture: the software security problem, the way static analysis can help, and options for integrating static analysis as part of the software-development process. Part II, "Pervasive Problems," looks at pervasive security problems that can impact software, regardless of its functionality, while Part III, "Features and Flavors," tackles security concerns that affect common flavors of programs and specific software features. Part IV, "Static Analysis in Practice," brings together Parts I, II, and III with a set of hands-on exercises that show how static analysis can improve software security.

Chapter 1, "The Software Security Problem," outlines the software security dilemma from a programmer's perspective: why security is easy to get wrong and why typical methods for catching bugs aren't very effective when it comes to finding security problems.

Chapter 2, "Static Analysis," introduces static source code analysis. It looks at the variety of problems that static analysis can solve, including structure, quality, and, of course, security. We take a quick tour of open-source and commercial static analysis tools.

Chapter 3, "Static Analysis as Part of Code Review," looks at how static analysis tools can be put to work as part of a security review process. We examine the organizational decisions that are essential to making effective use of the tools. We also look at metrics based on static analysis output.

Chapter 4, "Handling Input," takes an in-depth look at how static analysis tools work. We explore the essential components involved in building a tool and consider the trade-offs that tools make to achieve good precision and still scale to analyze millions of lines of code.

Part II outlines security problems that are pervasive in software. Throughout the chapters in this section and the next, we give positive guidance for secure programming and then use specific code examples (many of them from real programs) to illustrate pitfalls to be avoided. Along the way, we point out places where static analysis can help.

Chapter 5, "Handling Input," addresses the most thorny software security topic that programmers have faced in the past, and the one they are most likely to face in the future: handling the many forms and flavors of untrustworthy input.

Chapter 6, "Buffer Overflow I," and Chapter 7, "Bride of Buffer Overflow," look at a specific input-driven software security problem that has been with us for decades: buffer overflow. Chapter 6 begins with a tactical approach: how to spot the specific coding techniques that are most likely to lead to an exploitable buffer overflow. Chapter 7 steps back and examines some of the indirect causes of buffer overflow, such as attacker-controlled format strings and integer wraparound. We then step back and take a more strategic look at buffer overflow and possible ways that the problem can be tamed.

Chapter 8, "Errors and Exceptions," addresses the way programmers think about errors and exceptions. Although errors and exceptions are only rarely the direct cause of security vulnerabilities, they are often related to vulnerabilities in an indirect manner. The connection between unexpected conditions and security problems is so strong that error handling and recovery will always be a security topic. At the end, the chapter discusses general approaches to logging and debugging, which is often integrally connected with error-handling code.

Part III uses the same positive guidance and specific code examples to tackle security concerns found in common flavors of programs and related to specific software features.

Chapter 9, "Web Applications," looks at the most popular security topic of the day: the World Wide Web. We look at security problems that are specific to the Web and to the HTTP protocol.

Chapter 10, "XML and Web Services," examines a security challenge on the rise: the use of XML and Web Services to build applications out of distributed components.

Although security features are not our primary focus, some security features are so error prone that they deserve special treatment. Chapter 11, "Privacy and Secrets," looks at programs that need to protect private information and, more generally, the need to maintain secrets. Chapter 12, "Privileged Programs," looks at the special security requirements that must be taken into account when writing a program that operates with a different set of privileges than the user who invokes it.

Part IV is about gaining practical experience with static analysis. This book's companion CD includes a static analysis tool, courtesy of our company, Fortify Software, and source code for a number of sample projects. Chapter 13, "Source Code Analysis Exercises for Java," is a tutorial that covers static analysis from a Java perspective; Chapter 14, "Source Code Analysis Exercises for C and C++," does the same thing, but with examples and exercises written in C.

Conventions Used in the Book

Discussing security errors makes it easy to slip into a negative state of mind or to take a pessimistic outlook. We try to stay positive by focusing on what needs to be done to get security right. Specifics are important, though, so when we discuss programming errors, we try to give a working example that demonstrates the programming mistake under scrutiny. When the solution to a particular problem is far removed from our original example, we also include a rewritten version that corrects the problem. To keep the examples straight, we use one icon to denote code that intentionally contains a weakness:

We use a different icon to denote code where the weakness has been corrected:

Other conventions used in the book include a monospaced font for code, both in the text and in examples.

© Copyright Pearson Education. All rights reserved.

Read More Show Less

Customer Reviews

Average Rating 4
( 1 )
Rating Distribution

5 Star

(0)

4 Star

(1)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted July 29, 2007

    making more robust code

    Chess and West describe methods of building security into your coding projects. As an integral part of the development process. There are tools out there which perform the static analysis described in the text. These are far removed from the early tools, which the book correctly describes as glorified grep. (That is, they were merely fancy parsers.) The tools are not definitive, as you are cautioned. Often, their greatest virtue can be to point out source code that should be subject to manual scrutiny. In a large code base, of hundreds of thousands of lines, this can be invaluable assistance. A quick comparative summary of various bug and security tools is also provided in Chapter 2. Specifically, figure 2.2 is a nice qualitative summary of these tools. Various chapters of the book deal with problems also covered elsewhere. Like finding buffer overflows. Especially with string logic. While the Web also is now a source of weaknesses in web applications that are weak in input and output validation. You have to carefully filter anything that you solicit as user input on a web page.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)