There are several books out there that try to teach secure programming by relating it to good software engineering principles. The problem is, you can say things like "use encryption" all you want, but if you don't get far more concrete than that, people are going to get it wrong over and over again.
If you look at the book, while there are indeed plenty of pieces of code people can just use, we thoroughly discuss design and implementation issues for each of the examples we give. That is, we're covering far more of the things that really do go wrong than the average high-level book is going to be able to cover.
Good question. They're generally problems that one would find in an implementation done in any language. However, there are plenty of language-specific problems for other programming languages. Some of the most glaring exist for PHP and Perl.
Also, note that many programming languages are implemented in C, and have had or might have security problems relating to that. I've seen such problems in several common scripting languages. It is like that there are plenty of other problems like that waiting to be found.
Even worse, my name is on a book that is pink. That's the reason for the current site color, BTW. Plus, I suppose we like torturing people at the same time we're trying to help them.
This is not a very good (modern) guide. There are plenty of better guides (still free) to which we link on the web site, such as David Wheeler's HOWTO . The book is more about giving actual code examples on how to do things properly. And, oddly enough, all the code is also available for free on the web site.
Re:We really need a different language
on
Secure Programming
·
· Score: 3, Insightful
I would actually argue that the most common security problem in software systems is likely NOT the buffer overflow. Yes, the most common thing to see in places like bugtraq, etc. is the buffer overflow, but this is because people know how to find them and turn them into exploits ( and, the consequences are running code on a remote machine, which is pretty severe).
However, C and C++ are a fairly small part of the market these days, too. All the market data I've seen recently suggests that no more than 1/3 of commercial development is in one of these languages. It's probably less.
And, there are plenty of security problems that apply to all languages, such as problems in authentication systems that provide the attacker some kind of leverage (e.g., practical guessing attacks), other misuse of cryptography (e.g., misapplying SSL) and other generic input validation problems (e.g., SQL injection). These things come up in all languages, and are things people frequently get wrong.
If only it were that easy! Most of the stuff in the book applies to any language under the sun, but the examples are in C. If the book were just about protecting against buffer overflows, then it would have been 50 pages instead of 800. There's a ton of hands-on material on how to use cryptography correctly in an application. It's still amazing to me that about 90% of the time I see SSL/TLS integrated into an application, it's used in ways that are grossly insecure (e.g., a man-in-the-middle attack is easy). Also, we cover things like how to prevent common input validation problems that happen in any language (e.g., SQL injection).
This isn't true whatsoever. Only the most glaring issues are fixed. Currently, we're working on a Java Secure Programming Cookbook, and we'll get around to C# after that.
We do a lot of code auditing, and find about 4-5 serious security problems per thousand lines of code of C and C++ code. In languages like Java, we still usually find 1 or 2 such problems.
CDs in the book add to the production costs and generally result in a higher cost to the consumer. Instead, you should be asking for an accompanying web site from which you can download the code.
This has a further advantage in that, as inevitable bugs are found in the code, the code on the web site can be updated.
One thing the article was looking for is a very simple programatic interface to 3D graphics. Such a thing has been around since the mid-90's. The Alice projectaims to teach 3D programming to novice programmers, though more people who are high-school age or older.
O'Reilly has a good security bibliography here. Be sure to read Practical Unix and Internet Security (which is now in its third edition). Beyond that, pick some books that seem the most interesting to you.
Is this a troll? Nevertheless, it is stupid, for a few reasons:
1) The Mersenne Twister is not cryptographically secure.
2) Even if it were, it would still need to be seeded with entropy, such as the kind provided by the VIA generator.
3) There's a big difference between entropy and pseudo-random numbers, anyway.
4) Entropy is crucial in many security-related applications.
Of course, given sufficient entropy, you can stretch it out with a good cryptographic PRNG.
This is because RC4 has no significant attacks. Only the key setup had new significant problems, and there are two easy workarounds. That quickly brings RC4 back to the point where it's just as secure to use as AES in a streaming mode such as OFB or CTR.
That is, with every cipher out there, if you deploy it improperly, you might be subjecting yourself to problems. RC4 can still be deployed properly if you follow RSA's recommendations on how to use it.
This particular argument is stupid, because many machines don't use KDE or even XFree86. It's not something that is a required foundation of the system. Show me a Linux kernel without GNU utilities, though.
I fell in love because of the UNIX environment that can also run Office natively, meaning that I don't have to use Windows ever again.
Two years ago, I never would have considered a Mac, nor would anyone I know, except for artists. Now, my wife, my mother and about 85% of my technical friends are Mac users.
OS X really has something for everyone. My mother loves iTunes... it's so incredibly easy to use. My wife and I like the support for DVD burning. I've recently tried some PC products to do this, and they just aren't mature enough, whereas the Mac solution is simply brilliant.
Ease of use and a real UNIX architecture really make it worthwhile. The cost of hardware is a minus, but I feel it was worth the extra money.
Do you think a book on building secure software would be anything but laughed at if it didn't talk about buffer overflows?
Actually, in the book, we do talk about how insider attacks are the most common kind of attack, and we encourage people to consider that in their risk management process, through design and into implementation.
The problem of malicious insiders is one that the software can only deal with up to a point. You need to have good physical security and good network security (e.g., strong passwords, etc.) I think it'd be good to see a book on defending against malicious insiders, but you can bet it will focus more on aspects other than the software security.
Re:Secure Programming for Linux and Unix HOWTO
on
Building Secure Software
·
· Score: 5, Informative
This is indeed a good document. The best thing about it is that it's online, and therefore it can keep up with new things better than a print book.
Our book tends to go a lot deeper in general, though. In particular, David's has little to no code.
Actually, that's the thesis of the first couple chapters of the book. We discuss how to incorporate security into the design process from the beginning.
I'm one of the authors of Building Secure Software. First, thanks for the flattering review. We certainly worked hard on the book for a long time, and believe that we've produced something that's very useful for anybody involved in the development process.
That having been said, I would like to let you all know the shortcomings I see, even though they are all fairly minor:
1) The book hasn't really seen any substantial discounts, as far as I know. Being a 400 page hardcover book, it's somewhat expensive to begin with, and I'm sure some people won't buy it just for that reason. We've requested that the next printing be done in soft cover, but I don't think that's going to happen, unfortunately.
2) New books always have tons of little problems with them. Several unfortunate things have been noticed already. Most unfortunately, there were a few outdated or inaccurate statements on MS technologies. All of the problems we've found so far will be fixed in the next printing, which should be pretty soon. However, if you notice a problem, and don't see it on the web site's errata, send us e-mail.
3) The topic area is moving pretty rapidly. We essentially finished the text minus edits in February, 2001. Since then, there have been some new things come up the pike it would have been nice to discuss. Over time, we'll update the book's web site with articles that are interesting supplemental reading.
All in all, I hope that people get a lot out of the book, and that it does well enough that we'll have the opportunity to do a second edition at some point to make the book even better.
Slashdot Mirror
If you look at the book, while there are indeed plenty of pieces of code people can just use, we thoroughly discuss design and implementation issues for each of the examples we give. That is, we're covering far more of the things that really do go wrong than the average high-level book is going to be able to cover.
Also, note that many programming languages are implemented in C, and have had or might have security problems relating to that. I've seen such problems in several common scripting languages. It is like that there are plenty of other problems like that waiting to be found.
Even worse, my name is on a book that is pink. That's the reason for the current site color, BTW. Plus, I suppose we like torturing people at the same time we're trying to help them.
This is not a very good (modern) guide. There are plenty of better guides (still free) to which we link on the web site, such as David Wheeler's HOWTO . The book is more about giving actual code examples on how to do things properly. And, oddly enough, all the code is also available for free on the web site.
However, C and C++ are a fairly small part of the market these days, too. All the market data I've seen recently suggests that no more than 1/3 of commercial development is in one of these languages. It's probably less.
And, there are plenty of security problems that apply to all languages, such as problems in authentication systems that provide the attacker some kind of leverage (e.g., practical guessing attacks), other misuse of cryptography (e.g., misapplying SSL) and other generic input validation problems (e.g., SQL injection). These things come up in all languages, and are things people frequently get wrong.
If only it were that easy! Most of the stuff in the book applies to any language under the sun, but the examples are in C. If the book were just about protecting against buffer overflows, then it would have been 50 pages instead of 800. There's a ton of hands-on material on how to use cryptography correctly in an application. It's still amazing to me that about 90% of the time I see SSL/TLS integrated into an application, it's used in ways that are grossly insecure (e.g., a man-in-the-middle attack is easy). Also, we cover things like how to prevent common input validation problems that happen in any language (e.g., SQL injection).
This isn't true whatsoever. Only the most glaring issues are fixed. Currently, we're working on a Java Secure Programming Cookbook, and we'll get around to C# after that.
We do a lot of code auditing, and find about 4-5 serious security problems per thousand lines of code of C and C++ code. In languages like Java, we still usually find 1 or 2 such problems.
This has a further advantage in that, as inevitable bugs are found in the code, the code on the web site can be updated.
Alice uses Python for its programming language.
O'Reilly has a good security bibliography here. Be sure to read Practical Unix and Internet Security (which is now in its third edition). Beyond that, pick some books that seem the most interesting to you.
Is this a troll? Nevertheless, it is stupid, for a few reasons: 1) The Mersenne Twister is not cryptographically secure. 2) Even if it were, it would still need to be seeded with entropy, such as the kind provided by the VIA generator. 3) There's a big difference between entropy and pseudo-random numbers, anyway. 4) Entropy is crucial in many security-related applications. Of course, given sufficient entropy, you can stretch it out with a good cryptographic PRNG.
This is because RC4 has no significant attacks. Only the key setup had new significant problems, and there are two easy workarounds. That quickly brings RC4 back to the point where it's just as secure to use as AES in a streaming mode such as OFB or CTR.
That is, with every cipher out there, if you deploy it improperly, you might be subjecting yourself to problems. RC4 can still be deployed properly if you follow RSA's recommendations on how to use it.
This particular argument is stupid, because many machines don't use KDE or even XFree86. It's not something that is a required foundation of the system. Show me a Linux kernel without GNU utilities, though.
I fell in love because of the UNIX environment that can also run Office natively, meaning that I don't have to use Windows ever again.
Two years ago, I never would have considered a Mac, nor would anyone I know, except for artists. Now, my wife, my mother and about 85% of my technical friends are Mac users.
OS X really has something for everyone. My mother loves iTunes... it's so incredibly easy to use. My wife and I like the support for DVD burning. I've recently tried some PC products to do this, and they just aren't mature enough, whereas the Mac solution is simply brilliant.
Ease of use and a real UNIX architecture really make it worthwhile. The cost of hardware is a minus, but I feel it was worth the extra money.
The problem of malicious insiders is one that the software can only deal with up to a point. You need to have good physical security and good network security (e.g., strong passwords, etc.) I think it'd be good to see a book on defending against malicious insiders, but you can bet it will focus more on aspects other than the software security.
This is indeed a good document. The best thing about it is that it's online, and therefore it can keep up with new things better than a print book. Our book tends to go a lot deeper in general, though. In particular, David's has little to no code.
Nice FUD, but untrue. Gary got his PhD under Doug Hofstadter, then went directly to the company that is now Cigital.
Actually, that's the thesis of the first couple chapters of the book. We discuss how to incorporate security into the design process from the beginning.
I'm one of the authors of Building Secure Software. First, thanks for the flattering review. We certainly worked hard on the book for a long time, and believe that we've produced something that's very useful for anybody involved in the development process. That having been said, I would like to let you all know the shortcomings I see, even though they are all fairly minor: 1) The book hasn't really seen any substantial discounts, as far as I know. Being a 400 page hardcover book, it's somewhat expensive to begin with, and I'm sure some people won't buy it just for that reason. We've requested that the next printing be done in soft cover, but I don't think that's going to happen, unfortunately. 2) New books always have tons of little problems with them. Several unfortunate things have been noticed already. Most unfortunately, there were a few outdated or inaccurate statements on MS technologies. All of the problems we've found so far will be fixed in the next printing, which should be pretty soon. However, if you notice a problem, and don't see it on the web site's errata, send us e-mail. 3) The topic area is moving pretty rapidly. We essentially finished the text minus edits in February, 2001. Since then, there have been some new things come up the pike it would have been nice to discuss. Over time, we'll update the book's web site with articles that are interesting supplemental reading. All in all, I hope that people get a lot out of the book, and that it does well enough that we'll have the opportunity to do a second edition at some point to make the book even better.