Building Secure Software

greg pryzby writes: "A friend has been pushing me to read a number of technical books lately. After reading Building Secure Software: How to Avoid Security Problems the Right Way (BSS:HtASPtRW), I decided I needed to spread the word." Read on below for Greg's word on this one. Building Secure Software: How to Avoid Security Problems the Right Way author John Viega, Gary McGraw pages 528 publisher Addison-Wesley rating 8.5 reviewer greg pryzby ISBN 0201-72152-X summary Good information for anyone involved with the creation of software which should be secure.

BSS:HtASPtRW should be available at your favorite book outlet. It is available in hard cover from Addison-Wesley Professional Computing Series (white cover with blue strip). Since it is a security book, the forward is by Bruce Schneier and displayed on the cover. When you open the book, there are three pages of "Advanced Praise" for the book. So, the stage is set and the expectations are high. Will the book live up to the hype? I thought so.

Who should read the book? Anyone who cares about security. There is information for the manager, coder and everyone in between. Throughout the book, there are plenty of examples which I found very useful. John and Gary use code to show th at what they are talking about is not 'just theory'. That is right, there is code that shows the problems. That means samples of bad code, 'secure' code and code to show exploits.

I decided to look at a few chapters and talk about them specifically. Why did I pick these chapters? Because I found them interesting and thought others would too. I can't cover each chapter because I want John and Gary to write more books , so they need to sell a few copies!

Why do they do this? Isn't this giving the bad guys what they need? The bad guys have the information already. There is belief in the security community of full disclosure. This means not keeping things security and calling it secure. "Full disclosure means that hackers publicly disseminate information about your security problem, usually including a program that can be used to exploit it (sometimes even remotely)." (page 81)

Chapter 7 is on buffer overflows. I have read about buffer overflows for years. The chapter starts by explaining what a buffer overflow is and why it is a problem (pointy headed manager stuff). At this point John and Gary talk about how to protect yourself from buffer overflows. They start by listing problems in C and show why it is a problem. A list of functions that are 'bad' are given, but as any list, this isn't comprehensive. While avoiding the list is a good idea, you need to read why the calls are a problem so you can think about any call you use and why there maybe a buffer overflow.

The chapter then turns very technical. The difference between a heap and stack o verflow is discussed. An example is given that takes a C program and shows how to smash the heap and then how to smash the stack. This is pretty technical stuff , but very interesting. Finally an exploit is given. Very informative.

Chapter 9 is on race conditions. Time-of-check, Time-of-use (TOCTOU) is used to demonstrate a race condition. There is discussion on what a race condition is. John and Gary again step through code that is vulnerable and explain why it is vulnerable. Of course they show you how to write the code securely.

Chapter 10 is on randomness and determinism and lives up the the others. I know that random() isn't really random, is a pseudo-random number generator and should not be used when you need a real randomness. John and Gary give a great example to show how an online gambling poker application was open to cheating. Using some math and educated guessing, a GUI was written that would show you everyone's hand and how to win.

The next part of the chapter talks about how to generate randomness via software and hardware solutions. A discussion on entropy and how to determine the amount of entropy from the random source is given. Things get technical (I think), but you can follow the details or skim them. Regardless of how you decide to read this section, you will walk away with a better understanding of the problem.

I hope from the chapters I discuss, your curiosity has been peaked and you pick up a copy. There is other interesting stuff, like the 10 guiding principles for software security.

Web Resources
The web site recently was overhauled. The code from the book is there as well are web resources. It is worth it to take a look at the web site for more information and to get a feel for the information the book covers.

Contents
Foreword
Preface
Acknowledgments

1. Introduction to Software Security
2. Managing Software Security Risk
3. Selecting Technologies
4. On Open Source and Closed Source
5. Guiding Principles for Software Security
6. Auditing Software
7. Buffer Overflows
8. Access Control
9. Race Conditions
10. Randomness and Determination
11. Applying Cryptography
12. Trust Management and Input Validation
13. Password Authentication
14. Database Security
15. Client-side Security
16. Through the Firewall

Appendix A. Cryptography Basics
References
Index

You can purchase Building Secure Software from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Comments

security vs. trade secret

[telstar]

While open-sourcing your project may help ensure that you're a bit more proactive in securing your applications, it also gives the keys to the castle to anybody that decides to find programming mistakes in your code. Closed-source projects, while simply hiding any potential security holes, really does add an additional layer of protection, albeit a very thin one. But the issue of open-source vs. closed source as it relates to security is an entirely different argument of open-source vs. closed source as it relates to a company's right to keep trade secrets as just that. It's my opinion that if a company writes some code that they don't want shared, then they've got every right to keep it that way.