Slashdot Mirror
Secure Programming
viega writes "Matt Messier and I have just launched a secure programming web site. While this site does support our new book The Secure Programming Cookbook for C and C++ , it also serves as a thorough resource for developers. It has numerous links to articles and other topical resources, new recipes that demonstrate secure programming techniques a large glossary and the obligatory web log. We accept outside submissions, and will reward the best recipe submission each month-- O'Reilly will publish it on the O'Reilly Network web site and will give the author a free book. There's already a decent amount of new content, including recipes on avoiding malloc()/new-related integer overflows, watching out for security problems in API differences and issues when truncating data. There's also an RSS feed for the web log."
Or for a quick and free guide, you can download the secure programming faq from one of the oldest websites on the internet-
Securing Programming FAQ
--
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
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).
Been in the security game for 10 years...
From all these posts, it seems that all programmers don't have a clue about programming in a secure manner. I disagree, its just that times have changed.
Surely, a few years ago this was the case. But certainly not as bad as now. Most PHB worth their weight usually know the security buzz words associated with an implementation are. If they don't give support to the developers to create a secure solution, they arent just lacking in security skills - they are lacking in overall management skills and an understanding of IT. Security has to be part of the overall process when in development, PHB's must invest *training* for programmers and develop standards to follow.
Previous posters saying that it should be manditory for all post grads to have indepth security skills is down right short sighted. Security is a bottomless pit with many variables, a general subject can be taught. However, security can't stem strictly by programming practices. It is a collection of standards from all types, from the network, operating system to the application level. Not to mention the usual deal of people, process and technology.
I've lost count of how many pen tests I've completed where the application design was rock solid, however they had a bad password on their admin portal.
Nuff said....
Bah. That they do not have security holes is implausible, if not actually impossible, to prove. It's hard to even define what a security hole is; a changing threat model has "caused" many security holes. (Is an open relay a security hole? I say yes. Twenty years ago, everyone said no.) I doubt your statement. I can't point at a hole right now, but I have confidence that at least one security hole will eventually be discovered in those programs.
They were written using secure coding techniques that make them immune to things like buffer overflows. You can't "overlook" a buffer overflow with stralloc.
No, they make it easier to avoid buffer overflows. They don't prevent them: I quote from your hyperlink:
If they use sa.s and sa.len directly, they can screw up and increase len inappropriately. The API seems good in that it makes it much harder to do things wrong, but it is hubris to say it makes you invulnerable. Besides, buffer overflows are possible for things other than strings, so this solves only (the most common) part of the problem. And there's still the legacy code that people can use without porting to stralloc.
It does seem like a good library if you're stuck using C. Another alternative is APR, which makes managing all sorts of memory allocations much easier. Pools are handy things when dealing with a language that primitive.
But there are languages in which it actually is impossible to have a buffer overflow. Please don't confuse the issue by saying that this (which makes it somewhat easier to avoid this error) makes the error impossible.