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.
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.
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.
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.
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.
Security Engineering by Ross Anderson, the first version is available for free online as downloadable PDFs.
A couple other good books:
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.
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
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
19 Deadly Sins of Software Security: Programming Flaws and How to Fix Them (Security One-off)
There is also new edition 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them, but I didn't read it yet...
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:
All in all, you might get better mileage from reading something like The Pragmatic Programmer than a book about code security.
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:
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 ;)
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.