http://www.secureprogramming.com/ News & information related to secure programming topics en-us 2010-07-31T23:20:40+00:00 http://www.secureprogramming.com/?action=view&feature=weblog&weblogid=11 SafeStr v1.0.3 and XXL v1.0.1 have finally been released today. It's been far too long since the last release was made of either of these libraries, but better late than never I suppose. The... SafeStr v1.0.3 and XXL v1.0.1 have finally been released today. It's been far too long since the last release was made of either of these libraries, but better late than never I suppose. The new versions are primarily bug fixes, although some minor new function has been added to both. Thanks to everyone that has submitted bug reports and patches!]]> Matt Messier Matt Messier 2005-01-30T18:33:43+00:00 http://www.secureprogramming.com/?action=view&feature=weblog&weblogid=10 O'Reilly's DevCenter has posted three articles comparing Java and .NET security, with a fourth one coming in February. We'll update this story when the fourth article is available. Securit...

1. Security Configuration and Code Containment


2. Cryptography and Communication


3. Code Protection and Code Access Security (CAS)

]]> John Viega John Viega 2004-01-31T06:07:22+00:00 http://www.secureprogramming.com/?action=view&feature=weblog&weblogid=9 David LeBlanc, co-author of Writing Secure Code, has put together a C++ class to help developers avoid integer overflow errors. In addition, he wrote an article that is a lucid introduction t... Writing Secure Code, has put together a C++ class to help developers avoid integer overflow errors. In addition, he wrote an article that is a lucid introduction to the problem. The article, along with a link to the code, is available here.]]> John Viega John Viega 2004-01-22T22:44:48+00:00 http://www.secureprogramming.com/?action=view&feature=weblog&weblogid=8 Hey, we got reviewed on slashdot. Thanks for the positive review. reviewed on slashdot. Thanks for the positive review.

We have had several people tell us that they find the book very useful for other languages as well. I think it covers a lot of low-level implementation stuff that isn't available in other books, and is useful as long as you can READ C code. If there's anything people want to see for other languages, etc., feel free to send us email suggesting it. We will have frequent updates to this web site with new content (at least monthly). Much of the content will be for other languages.]]> John Viega John Viega 2003-10-08T18:07:49+00:00 http://www.secureprogramming.com/?action=view&feature=weblog&weblogid=7 Dan Weeks wrote the first published review of the book we've seen so far. published review of the book we've seen so far. ]]> John Viega John Viega 2003-09-16T10:41:21+00:00 http://www.secureprogramming.com/?action=view&feature=weblog&weblogid=5 We've now been slashdotted. After lowering the idle connection timeout from hours to minutes, we're doing fine (famous last words). The comments are full of "C sucks" rants. I tho... slashdotted. After lowering the idle connection timeout from hours to minutes, we're doing fine (famous last words). The comments are full of "C sucks" rants. I thought I'd summarize a few of my thoughts on this issue.

Yes, C and C++ have special "features" that make adding security problems easy, even for a fairly informed and careful developer. That's impossible to deny, though the book and this site do cover mitigation strategies that can make a big difference. However, people are miscalculating by assuming that just switching to another programming language is going to make a big difference. It can make a difference, but not as big of one as people are expecting. Defensive practices can offset the problem.

We've done a few case studies on number of defects per line of code when performing code audits. C and C++ programs have averaged 4-5 security-critical defects per thousand lines of code. Java programs still average 1-2 security-critical defect per thousand lines.

There are plenty of problems that programming languages themselves haven't fixed. And, honestly, most of those problems should be fixed at the API level. For example, it's stupid that neither OpenSSL or Microsoft supports full certificate validation by default. The programmer has to know what security checks to perform and write the code to do them manually, instead of getting "secure by default" behavior. As a result, most applications that use SSL/TLS are vulnerable to man-in-the-middle attacks. Sure, this is a problem in some common C-based libraries, but it's just as common in the SSL implementations for other languages. Other problems such as cross-site-scripting and SQL injection affect other languages far more commonly than C and C++, since those languages aren't often used in web apps.

In C and C++, the common security problems are relatively easy to understand, and if you are diligent and take the right preventative measures, they're not so hard to avoid. In other languages, the easy/obvious problems don't apply, but as people use high-level primitives to build complex applications, they tend to introduce complex security problems (race conditions in servlets can be quite tough to identify, and still have security implications).

In short, you aren't likely to accidentally end up with a "secure" program, no matter which programming language you use. We're currently working on a Java Secure Programming Cookbook, and are assembling a team for a PHP Secure Programming Cookbook. There's plenty of material for both books, without question. Expect both to be at least 400 pages, without even covering all of the low-level cryptographic stuff we cover in the C/C++ version.

At the end of the day, if you're going to be diligent, then security can be reduced to a fairly minor consideration in programming language choice.

One final note: C++ is often perceived as being more secure than C, because it has an abstracted string type. That's not really true, even ignoring the few cases where you can still overflow using C++ strings. Basically, heap overflows are far more dangerous in C++, because lots of function pointers tend to be stored on the heap, due to the way classes and exception handling is implemented (the GOT is stored on the heap even in C programs, but C++ programs tend to have function pointers coming out of the wazoo). If an attacker can overwrite one of those pointers, then it's often possible that he can replace it with a pointer to some sort of malicious payload.]]> John Viega John Viega 2003-09-15T07:59:37+00:00 http://www.secureprogramming.com/?action=view&feature=weblog&weblogid=4 One of the goals of SecureProgramming.com is to provide recipes demonstrating good secure programming techniques (particularly ones supplementing our books). Anyone can submit these recipes. ... SecureProgramming.com is to provide recipes demonstrating good secure programming techniques (particularly ones supplementing our books). Anyone can submit these recipes.

Every month we will pick the best submitted recipe. O'Reilly will provide the winner with a free O'Reilly book (the winner's choice) and will publish the recipe on the O'Reilly Network.

Submit recipes here. Please avoid anything that duplicates material in the Secure Programming Cookbook for C and C++ (though similar recipes for other programming languages are certainly welcome). ]]> John Viega John Viega 2003-09-13T23:31:13+00:00 http://www.secureprogramming.com/?action=view&feature=weblog&weblogid=3 Modern Cryptography is by far the best first text on cryptography I've ever seen, blowing books like Applied Cryptography out of the water. It's a clear treatment that focuses on building pra... Modern Cryptography is by far the best first text on cryptography I've ever seen, blowing books like Applied Cryptography out of the water. It's a clear treatment that focuses on building practical systems, focusing on how to avoid common pitfalls.

The focus of this book is the correct design of cryptographic protocols that resist attack. This is in contrast to books like Applied Cryptography, which focuses on the tools and the building blocks used to construct systems, glossing over how to use those things together to build strong systems. While the innards of block ciphers and so on can be interesting, Schneier himself is prone to saying something along the lines of, "The world is filled with insecure systems built by people who read Applied Cryptography". That is, in order to build secure systems with cryptography, one should understand how to use cryptographic tools properly. We do not need to know how the tools themselves work... we can take it for granted as long as we understand their behavior.

It must be said that the average person shouldn't be designing their own cryptographic protocols, either. One of the things this book does well is demonstrate the large number of non-intuitive ways in which cryptographic protocols can go wrong. For example, the chapters on authentication schemes demonstrate a large number of schemes authored by reputable cryptographers that turned out to have significant weaknesses.

For the above reason, this probably isn't a text that needs to be on everybody's desk. I would say it is essential for anyone who wants to understand why protocol design is so hard, and it is also valuable to the few people who will go on to build new protocols, particularly graduate students in cryptography.

Here's what I like about the book:

• Cryptography is a rapidly evolving field, and this book is quite up to date, covering AES and other recent protocols. This is quite in contrast to books like Applied Cryptography, which is painfully out of date.
• The text is pretty lucid, staying away from arcane mathematical symbols when possible, and explaining them well when not. While it's a bit more math-y and not quite as fun to read as Applied Cryptography, it is nearly as good in this respect, and the content is far better.
• It's the first book I've seen to do a good job covering the state of the art in provable security techniques. It introduces fairly recent provable security models, and does so in a way that it doesn't take a mathematician to understand.
• Its coverage of topics is great, particularly in that it spends much time examining real-world protocols such as SSL/TLS, SSH and Kerberos.

Another recent book that tries to teach people how to engineer secure systems using cryptography is Practical Cryptography, by Niels Ferguson and Bruce Schneier. Unlike that book, Modern Cryptography is far more thorough and detailed. It doesn't preach a single, inflexible way to do things (that is often overkill). And, honestly, it doesn't assume the reader is too dumb to understand the theory. If you don't want to understand the theory, if you just want to build secure systems using cryptography, then neither of these books is really targeted to you (particularly because neither book contains any real code, only algorithm descriptions).

If you are in the target audience for this book, you won't regret buying it. Even at the $54.99 list price (which is what I paid, sadly), you shouldn't feel even remotely cheated, particularly considering the fact that there are shorter books with only a fraction of the content that cost a lot more.

---

Modern Cryptography: Theory and Practice
by Wenbo Mao
Hardcover, 698 pp.
Published by Prentice Hall PTR; 1st edition (July 25, 2003)
ISBN: 0130669431
Order from Amazon.com.]]> John Viega John Viega 2003-09-13T23:09:03+00:00 http://www.secureprogramming.com/?action=view&feature=weblog&weblogid=2 SafeStr 1.0.0 has been released, and is available from zork.org. The goal of the SafeStr library is to provide a rich string-handling library for C that has safe semantics yet interoperates w... zork.org. The goal of the SafeStr library is to provide a rich string-handling library for C that has safe semantics yet interoperates with legacy library code in a straightforward manner. Additionally, porting code that uses standard C string handling should be straightforward. The library should work on all modern Unix-like platforms, as well as any 32-bit Microsoft Windows OS. See also the software package listing on this site.]]> Matt Messier Matt Messier 2003-09-10T21:19:05+00:00 http://www.secureprogramming.com/?action=view&feature=weblog&weblogid=1 Welcome to SecureProgramming.com! The goal of SecureProgramming.com is to provide a resource for programmers to find information on secure programming, whether it's for C/C++, Java, Perl, P... Welcome to SecureProgramming.com!

The goal of SecureProgramming.com is to provide a resource for programmers to find information on secure programming, whether it's for C/C++, Java, Perl, Python, or any other language. Our intention is to supply the site with our own content as well as accept submissions from visitors to the site that will be beneficial to others. Site content will be strictly limited to secure programming topics.

We're in the initial stages of launching the site, so not everything that we have planned is up and running yet. Most notably, we are still somewhat short on supplemental recipes, but we hope to change that fairly quickly, both with our own content and with submissions from visitors to the site.

Finally, all of the code that makes up the site was written from scratch and hasn't been tested as extensively as we might like with a wide array of browsers just yet. We expect that there'll probably be some issues with various browsers, so please let us know of any serious problems that you encounter.]]> Matt Messier Matt Messier 2003-08-31T07:04:11+00:00