Software Security: What To Look Out For
There has been a lot of news lately about computer security breaches. With our entire world online this is a huge deal. Companies have spent a lot of advertising dollars on easing consumers concerns about Internet security. As a byproduct people have certain expectations (no matter what the fine print disclaimer says).
From my experience, it seems that for some reason “higher-ups” in organizations see software security as an afterthought. For some, it is more important to launch a product now and worry about fixing holes later. Many business folks that I’ve met say it’s more important to get to the market first than anything else. In a business context this makes sense, but once a security breach occurs the damage is not easily correctable. You could lose your client base forever!
There are things that developer’s do that can contribute to their software being weak in the security department. Here are a few off the top of my head:
Heavy reliance on open frameworks
I am a huge open source advocate so this is not easy for me to say. There are some inherit dangers with heavy reliance on open platforms. They seem to be more susceptible to attack (or at least attempts). The specs (and in many cases the source code) are openly available to anyone. This gives hackers an opportunity to evaluate the code and find weaknesses. Eventually hackers will perform bulk attacks on systems suspected of running potentially vulnerable software. If a specific software framework has been exposed then many hundreds or thousands of products are vulnerable.
It really sucks to reinvent the wheel all the time, so using prepackaged frameworks makes sense. My advice is to add at least some level of customization to give your software uniqueness.
A simple example is if you are using a PHP based web framework that has an administrator page called ‘administrate.php’ configure the framework to use a different filename. Sometimes it is literally that simple to protect your software.
Lack of input validation
No matter how secure a piece of software is; a failure to validate user input will eventually result in some sort of code injection. This has bitten the asses of many people I know in this business (Myself included). It is a lesson learned early in a developer’s career and sometimes it can be quite devastating. In the past, simple things like text messages were used to transmit malicious code because the software failed to scan the input before processing it. There are literally thousands of examples of this type of vulnerability.
Unnecessarily frequent password change intervals
I have always had a problem with this security policy. In organizations where most people are not high tech but use computers for their work activities this is so dangerous. Some organizations will require password changes once a month, and on top of that; passwords can never be repeated. This only increases the chance that someone will write the password down or put it on an iPhone, Android, or Blackberry password storage app! Someone steals your phone you could be in trouble. Someone walks by your desk and sees a sticky note with your password on it, again you could be in trouble.
Passwords are a simply way to manage security but, perhaps, as we progress as a techno-literate culture we need to come up with a better way of authenticating people. Eye scans, thumb prints, voice recognition, something better than passwords.
Failure to Review Inherited code
As Bryan and I said before, reading someone else’s code can be a pain. But, you have to know how to do it. Many companies want to reuse as much code as possible because (obviously) it saves time and money. The problem is, sometimes this code can have logical errors that can open a security hole. If the implementers do not properly audit the code then there may be a problem down the line. Never assume that code you inherit (or even your own code) is perfect. Always have a few people look at it.
I bring this one up because recently I was asked to review some ASP code and I noticed that at one point it was passing a username and password in plain text as a GET variable on the address bar. I couldn’t believe my eyes.
I want you guys to be competent, confident, and ridiculously awesome programmers. Since security is a hot topic and it will likely always be, please take the time to audit your code for security vulnerabilities. There are a lot of proper guidelines you can follow, but sometimes it is literally as easy as changing a filename to thwart a hacker, or asking 3 or so of your fellow developers to review your code. Code reviews are fun and enlightening. Unless you are working on proprietary software or your contract states you cannot share code with outsiders, sometimes it is good to get a few friends together that work for different companies and code review! This is fun because you get a lot of different opinions in the room.