In today's software development environment, a developer would be extremely remiss if they did not consider security when designing and implementing applications. Unfortunately, what each developer considers secure programming varies widely. This is partly because when being taught software development (or for you autodidacts, learning it on your own), generally speaking most materials and courses do not cover the information required to make informed security decisions. On top of this, developers are human and do make mistakes, and lets face it guys and gals... we’re lazy. (Excluding Bulletproof developers of course! :)). That is, being human, we sometimes cut corners, and sometimes, they come pre-cut.

      The goal of this blog-sequence is to guide you developers in making informed decisions about what is and is not secure coding practice. However, it is not enough for you to understand that non-secure coding practices are bad, you need to understand why they are bad. Why? Well, because we can't cover every situation... Each situation is different, sometimes vastly, but if you have a good grip on how to find vulnerabilities in something, you'll have a much better idea of how to avoid them as well.

      The blog sequence is twenty sequential articles covering a number of types of software development security vulnerabilities and solutions for how to avoid or eliminate them.

      Please note that most of the posts in this blog sequence will involve code examples in C. However, these vulnerabilities can be realized (with a few exceptions) in all languages.  In many cases they are a function of the algorithms or design decisions for a piece of software, and not a function of the language which the software was implemented in.

        The sequence of blog posts will cover the following topics:

•       Developing secure software, an overview
•       Fail closed vs. fail open systems design
•       Information disclosure vulnerabilities
•       Race conditions
•       Privilege confusion, vertical and horizontal privilege escalation
•       Vulnerable deputy situations
•       Buffer overflows
•       Format string overflows
•       Code injection
•       SQL injection
•       Security and the web
•       Directory traversal
•       Vulnerable CGIs
•       Stealing a session
•       Data vulnerabilities in web forms and query strings
•       Click-jacking
•       Phishing
•       XSS and CSRF vulnerabilities
•       Thinking security when writing code
•       The importance of peer review for security and code quality

      While this list is by far not a complete guide, it certainly covers a large part of the vulnerabilities that are seen in software, and will give your software at least a fighting chance when your application goes up for audit, or worse goes up against someone determined to exploit it.

Please join us next time, for the first in-depth article, Hack me, I'm yours!