- Series: Security One-off
- Paperback: 304 pages
- Publisher: McGraw-Hill Osborne Media; 1 edition (July 26, 2005)
- Language: English
- ISBN-10: 0072260858
- ISBN-13: 978-0072260854
- Product Dimensions: 7.4 x 0.6 x 9.3 inches
- Shipping Weight: 1.1 pounds (View shipping rates and policies)
- Average Customer Review: 4.3 out of 5 stars See all reviews (14 customer reviews)
- Amazon Best Sellers Rank: #1,632,430 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
19 Deadly Sins of Software Security: Programming Flaws and How to Fix Them (Security One-off) 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
There is a newer edition of this item:
Frequently bought together
Customers who bought this item also bought
From the Back Cover
“Ninety-five percent of software bugs are caused by the same 19 programming flaws.” —Amit Yoran, Former Director of The Department of Homeland Security’s National Cyber Security Division
Secure your software by eliminating code vulnerabilities from the start. This essential book for all software developers--regardless of platform, language, and type of application--outlines the 19 sins of software security and shows how to fix each one. Best-selling authors Michael Howard and David LeBlanc, who teach Microsoft employees how to write secure code, have partnered with John Viega, the man who uncovered the 19 deadly programming sins to write this hands-on guide. Detailed code examples throughout show the code defects as well as the fixes and defenses. If you write code, you need this book. Eliminate these security flaws from your code:
- Buffer overruns
- Format string problems
- Integer overflows
- SQL injection
- Command injection
- Failure to handle errors
- Cross-site scripting
- Failure to protect network traffic
- Use of magic URLs and hidden forms
- Improper use of SSL
- Use of weak password-based systems
- Failure to store and protect data securely
- Information leakage
- Trusting network address resolution
- Improper file access
- Race conditions
- Unauthenticated key exchange
- Failure to use cryptographically strong random numbers
- Poor usability
Michael Howard, CISSP, is an architect of the security process changes at Microsoft and a co-author of Processes to Produce Secure Software published by the Department of Homeland Security’s National Cyber Security Division. He is a Senior Security Program Manager in the Security Engineering Group at Microsoft Corporation and co-author of Writing Secure Code (Microsoft Press). David LeBlanc, Ph.D., is Chief Software Architect for Webroot Software, and was formerly Security Architect in the Office group at Microsoft. He is co-author of Writing Secure Code. John Viega is the CTO of Secure Software. He first defined the 19 deadly sins of software security for the Department of Homeland Security. He is co-author of many security books including Building Secure Software (Addison-Wesley).
About the Author
Michael Howard is a senior security program manager in the security engineering group at Microsoft Corporation, and a co-author of the award-winning Writing Secure Code. He is a co-author of Basic Training in IEEE Security and Privacy Magazine and a co-author of the National Cyber Security Task Force “Processes to produce Secure Software” document for the Department of Homeland Security. As an author of the Security Development Lifecycle, Michael spends most of his time is spent defining and enforcing security best practice and software development process improvements to deliver more secure software to normal humans.
David LeBlanc, Ph.D., is currently Chief Software Architect for Webroot Software. Prior to joining Webroot, he served as security architect for Microsoft's Office division, was a founding member of the Trustworthy Computing Initiative, and worked as a white-hat hacker in Microsoft's network security group. David is also co-author of Writing Secure Code and Assessing Network Security, as well as numerous articles. On good days, he'll be found riding the trails on his horse with his wife, Jennifer.
John Viega discovered the 19 deadly programming flaws that received such press and media attention, and this book is based on his discovery. He is the Founder and Chief Scientist of Secure Software(www.securesoftware.com), is a well-known security expert, and coauthor of Building Secure Software (Addison-Wesley), Network Security with OpenSSL (O'Reilly) an Adjuct Professor of Computer Science at Virginia Tech (Blacksburg, VA) and Senior Policy Researcher at the Cyberspace Policy Institute, and he serves on the Technical Advisory Board for the Open Web Applications Security Project. He also founded a Washington, D.C. area security interest group that conducts monthly lectures presented by leading experts in the field. John is responsible for numerous software security tools, and is the original author of Mailman, the GNU mailing list manager. He holds a B.A. and M.S. in Computer Science from the University of Virginia. He is the author or coauthor of nearly 80 technical publications, including numerous refered research papers and trade articles. He is coauthor of Building Secure Software, Network Security and Cryptography with OpenSSL and The Secure Programming Cookbook for C and C++.
Browse award-winning titles. See more
If you are a seller for this product, would you like to suggest updates through seller support?
Top Customer Reviews
His chapter on password systems alone is worth the price of the book. Summary: passwords are a lousy security measure that's riddled with holes but we seem to be stuck with them so we might as well make the best of it.
Not all the writing is bad. For example, the chapter on cross-site scripting is the clearest explanation of this threat that I have come across.
But sometimes, the writing is so bad that word choice appears to have been random. For example, here is a paragraph describing the problem with the SSL API:
"The problems with SSL are the fault of the API, not the underlying programming language. Therefore, any language can be affected. HTTPS APIs tend to be less problematic than generic SSL, because the HTTPS protocol mandates authentication checks that general-purpose SSL protocol leaves as optional. As a result, APIs tend to leave this responsibility up to the user."
I'm immediately put off by the phrase "underlying programming language" being used to describe the language calling an API, since the usual metaphor is that you call "down" into an API. The next sentence, about HTTPS being less problematic than generic SSL, makes sense, but how does this result in APIs leaving responsibilities to users?
No big deal: the gist is that it is not as easy to make security errors in HTTPS as it is with generic SSL libraries, although the passage does not speak well of the editors at McGraw Hill.
Examples of contractions include the use of regular expressions to locate problematic user input (don't use them because they are too hard to understand and hence prone to error; do use them because they are powerful) and quoting user input from web forms (it's easily circumvented, but do it). The point is that complex regular expressions may not match what you expect or what a malicious user can create, and quoting input is not sufficient protection.
I believe that a problem faced by "how-to" books on security is that the topics and tidbits do not sort out neatly into categories. Also, there are strengths and weaknesses to many of the mitigation strategies. And my guess is that engineers and techies get pushed into turning PowerPoint slides into paragraphs, even if there is not much logical connection between the bullet points of a slide.
That said, with his books "Applied Cryptography" and "Cryptography Engineering", Bruce Schneier has demonstrated that it is possible to write well and lucidly on some of the most difficult topics in computer security. If only more writers aspired his example!
Overall, a good introduction to information about common security flaws and problems. Recommended for any software developer.
production of more security software.
The main reason to read 19DS is to quickly become acquainted with various security problems facing software developers. At less than 300 pages, it's not a thick tome like WSC2E. 19DS also is not afraid to mix bugs (coding errors, like buffer overflow conditions) with flaws (design problems, like "failing to protect network traffic.") This sort of lax categorization bothers me (and Gary McGraw, as noted in his book "Software Security"), but it shouldn't interfere with the quality content of 19DS.
Probably the most interesting aspect (to me) of 19DS was sin 10, which discussed problems with Secure Sockets Layer (SSL). The chapter didn't describe algorithmic or protocol problems. Instead, it explained how programmers make poor assumptions about the features provided by their language of choice with respect to SSL. For example, many SSL libraries do not properly validate certificates. Without this functionality, the authors argue that SSL is almost worthless. While I don't necessarily agree with this statement, I really like reading this sort of criticism. I'd like to note that p 134 berates Python's ssl() but ignores pyOpenSSL, which probably provides the features the authors would want.
Other "sins" take slightly different looks at security issues. Sin 17, for example, explains the importance of key exchange AND authentication. These are the sorts of problems I imagine are only discovered by examining multiple real-world implementations, and I value the authors sharing their experiences.
I subtracted one star because the quality of the "sins" isn't even. Some don't adequately explain the problem at hand (e.g., integer overflows). If the authors assume the reader knows the problem well enough to not introduce it properly, then why discuss it at all?
Overall, however, 19DS is a great book to get to your developers. It's short enough that they might actually read it, and the content is presented in a convincing enough manner to perhaps influence their coding choices.
Most Recent Customer Reviews
software security. It is short enough and easy enough to follow that it
might also be a good...Read more