views:

1047

answers:

16

What is the best book to read about security issues that should be kept in mind while programming?

What should a c++ programmer know about security?

Is it worth buying any one of the following book If so which one should I get.

  1. Secure Coding In C & C++ Secure
  2. Programming Cookbook for C and C++
  3. Writing Secure code
+6  A: 

http://www.owasp.org/

S.Lott
+1  A: 

Not specific to C++, but James Whittaker's How to break software security and How to Break Software are a great read, and should be very relevent.

Shane MacLaughlin
+16  A: 

This is a recent study about the Top 25 programming errors which cause security issues. If you can stay away from these you will be writing fairly secure code.

I think for a book you would probably want something more domain specific. Web aps have a whole heap of different security issues to say writing aps for a mobile phone.

Jeremy French
Please note, that the list has been updated at Feb 17 2010. The link posted is still correct - it points to the now updated page.
RED SOFT ADAIR
The Top 25 programming errors seems to be heavily web-centric... just saying.
ceretullis
+13  A: 

Writing Secure Code, published by Microsoft (cue sarcastic comments), is a very good general security reference for Windows developers specifically and is also useful in the more general case for other environments. I understand it was required reading for developers at Microsoft during the Vista development cycle.

Stu Mackellar
Should emphasize that its not limited to Windows programmers. Really the most important security book for any programmer, in any technology and any platform.
AviD
hahahahaha Vista
Matt Joiner
+5  A: 

Security Engineering by Ross Anderson, the first version is available for free online as downloadable PDFs.

Einar
+1  A: 

SecureCoding for c,c++ developer

yesraaj
A: 

A couple other good books:

  • Writing Secure Code by Microsoft Press
  • Threat Modeling by Microsoft Press
atk
+7  A: 

OWASP

The Open Web Application Security Project (OWASP) is an open-source application security project.

OWASP is not affiliated with any technology company, although it supports the informed use of security technology.

OWASP's most successful documents include the book-length OWASP Guide and the widely adopted OWASP Top 10 awareness document.

The most widely used OWASP tools include their training environment WebGoat, their penetration testing proxy WebScarab, and their OWASP .NET tools. OWASP includes roughly 100 local chapters around the world and thousands of participants on the project mailing lists.


From their website: http://www.owasp.org/

The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software. Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license.

You'll find everything about OWASP here on our wiki and current information on our OWASP Blog. Please feel free to make changes and improve our site. There are hundreds of people around the globe who review the changes to the site to help ensure quality. If you're new, you may want to check out our getting started page. Questions or comments should be sent to one of our many mailing lists. If you like what you see here and want to support our efforts, please consider becoming a member.

We ask that the community look out for inappropriate uses of the OWASP brand including our name, domain, logos, project names, and other trademarks and report issues to owasp(@)owasp.org or click here. OWASP Foundation does not endorse or recommend commercial products or services allowing our community to remain vendor agnostic with the collective wisdom of the best minds in application security worldwide.

Jon Winstanley
A: 

as long as you have all buffers under control and a tap on the sequence followed in case of all inputs does not go out of the algorithm...the program will perform fine

Hitesh Dharmadasani
Can't wait to play with one of your programs. ;-)
DevSolar
+4  A: 

You might want to keep the online version of these in mind over the print ones because of the updates and useful comments:

https://www.securecoding.cert.org/confluence/display/seccode/CERT+Secure+Coding+Standards

Ioan
+1 I bet most people buying the books are not aware that the same information is available online for free. I know I thought "cool!" until I saw it was basically a dump of the website.
jbcreix
+1 This one is highly useful and should be on the list. It's an "index" book while Robert Seacords other great book (Secure Coding in C and C++) is a "reading" book
joveha
+2  A: 

Ideally, you should read all three. And also read every article ever written on programming security. But we don't live in an ideal world, which is part of the reason why you need to worry about security in the first place. Out of the three, I have only read Writing Secure Code, but what others have said is also correct:

  • Keep good coding standards, consistent styling, etc. This way, if/when you write a vulnerability, you can locate it easily and fix the problem.
  • The "low hanging fruit" of security vulnerabilities are based off of attempted optimization. Reusing buffers, etc. Let the compiler handle the optimization, and focus on building your system.
  • The more devilish security problems are typically a result of the underlying design. A vulnerability in a protocol is much more devious than a buffer overflow. Get your design set, and test your algorithms before writing your code.

All in all, you might get better mileage from reading something like The Pragmatic Programmer than a book about code security.

SEK
A: 

I don't know any good books, but I do have some advice, mostly language-agnostic:

The most thing to do when writing secure software is to think about security! It seems simple, but I think a lot of the insecure software out there is insecure not because of bad design, but because it wasn't designed to be secure, or it blindly uses components that weren't designed to be secure.

Particularly important times to think about security are when you:

  • Define a protocol that might be used outside your application
  • Use external components, or use input from external components, the security of which you rely on a third party for.
  • Make assumptions about any external environment: think very carefully before assuming anything.

And if you are in control of the operating system, and you care about security between processes (for example, on an embedded platform):

  • Make sure you know the architecture inside out, memory protection, 'unprivileged modes' and other features only work if you use them properly, and they are often complex and difficult to use properly.

  • Consider which hardware might be hostile - ie, it is very easy for someone to plug in an evil USB device, or to sniff a serial interface, considerably more difficult for someone to get at what's in the on-chip memory cache.

  • Of course to be as secure as possible, you need your hardware (or more probably ROM software) to verify your software at boot-time, and then for the hardware-verified software to verify everything it launches, and so on, not much the programmer can do about this if the bottom is missing from the pyramid though :)

(as an aside, I'd wager a fair amount that Apple's shiny pad thing checks code signatures running on every processor from the ground up, and thus will probably never be unlocked...)

In short: don't assume anything, and it never hurts to think with a black hat on ;)

Autopulated
A: 

Writing Solid Code is a good book to consider from a security aspect. It is very old (1993) and is not billed as a security book, but it has extremely good advice aimed at writing as few bugs as possible, which is a non-trivial part of producing secure code.

It is a C-centric book but it has concepts that are language agnostic. For example, it dedicates a chapter to stepping through your code with a debugger. When I read the book, that practice was not something I always did, but now it is a critical step involved in all code that I write.

Mark Wilkins
A: 

Bruce schneier's: Applied Cryptography and Secrets & Lies

M.A. Hanin