Programmers and Their Sins

Pick Yin, On Programmers list seven programming sins - she got those from CHIP magazine and CHIP magazine got those from Defcon. From the list, numbers 1 (shatter attacks) and 6 (sql injection) are, in my opinion, the worst programming sins evah. But this is just touching the surface when it comes to security. Both are a result codes that does not properly validates input. The consequences of this are severe - buffer overflows, sql injection (which is so rampant, tons of local websites that belong to mobile operators, finance institutions and others are vulnerable to this), remote command execution, authentication bypass, etc.

But the thing is - I don't think that these errors can be considered programming sin. Sin is a strong word to use, especially when that label is applied to programmers. I would rather say that these are security oversight by the programmers - but then again, the blame is not totally them (unless you are talking about Microsoft). The problem is in software development, most specifically, software development management. Putting security into each stage of the software lifecycle is what is missing today. Products are pushed to the market with bleeding-edge functionalities (or we lose our customers to Acme company). Products are pushed to the market in the shortest time possible (sorry guys, our budget have been in half). Due to this, there is not place for security. Why? Because first of all, security is a process, and second of all - security is not a priority.

Writing a good code is easy. Writing a good code based on a company's coding standard is also easy to do. Testing - its even easier. There are tons of tools out there to help you perform performance, unit and functional testing. There's also tools to help you manage bugs. And tools for version control. But there's so few tools to help you find security flaws in your codes. Very few. And even if there is, how many of you have heard of splint? What programmer would bother to mess with propolice on their development server? So, it is a sad of affair for security. I think, from program managers point of view (that is, your project manager), the only time when security crops during development is when the app needs to validate user. Here the security is done through authentication codes (usernames, passwords) and controlled using authorization codes (who can do what).

But all is not lost. Let's get back to the list. The two that I mentioned is a result of not validating input. Solution is - either you are a programmer or a program manager - tell yourself and your team - do not trust input. With this is your head - you are making the first step towards writing secure codes. And this will also be your first step of making a security a part of your software development process. Say it with me again: do not trust input. If the input is an integer, make sure it is an integer. If the input is a string, make sure it is a string.

So go off now. Do something productive. Do not trust input, trust me on that.