Home > Security

Computerworld - In my previous column, I described how I found out that my company has some developers writing a new application, which I found out about when they came to me for advice on how to store passwords securely in their database. My advice on authenticating users was to use existing software services, rather than building an inferior duplicate. Subsequently, I've had several conversations with the developers about how to improve the security of their code. Coincidentally, my co-columnist Mathias Thurman has also been dealing with the subject of secure software development.

I've had to get back to basics with our developers. As it turns out, security really is an afterthought in their minds. I was surprised to learn that the developers aren't really familiar with what I consider to be the basic fundamentals of secure coding. I'm not a programmer myself, but I would have expected professional programmers to be more knowledgeable than me. In fact, don't they teach this stuff in college? Evidently not.

In my opinion, the first and most important security precaution that needs to be taken is to validate all inputs. The No. 1 cause of software vulnerabilities (at least until recently, since the threat landscape is always evolving) is buffer overruns. This is the classic path of attack that is easy for an attacker to exploit. When a piece of code accepts input from a user or another piece of software, that input is written to a memory buffer. If the data overflows into the memory space of another process, it can change the behavior of that other process in such a way that an attacker can take advantage, potentially gaining unauthorized access or data on the system.

The best defense against this is to build an extra check into the software that rejects any unexpected input. Every programmer should know how to do this, and they should regularly check all inputs in their software. This requires extra effort and more lines of code, but the security and quality of the software are greatly improved. And the user (or software) providing the data will receive an informative, helpful error if they provide incorrect data. Input validation is a win-win situation for everyone. I can't believe they haven't been doing this all along! And the security manager is the one telling them about it.

Cross-site scripting is another common vulnerability in Web-based software like ours. Everybody has heard of this, but apparently not everyone is defending against it. Cross-site scripting attacks rely on an attacker including a command into the input to a website, much as with buffer overruns. Attackers can run these commands on the server via the Web code, which can allow them to corrupt the website content or even take over the server itself. The solution is the same as for buffer overruns -- check the inputs! If the Web server is expecting a piece of data, say a ZIP code, it should look for specific formats. Something that looks like a software command, which doesn't belong in a ZIP code field, should be automatically rejected, because it doesn't fit the format. This is a simple concept, but it requires a bit of extra work by the developers. Again, it's mutually beneficial because the software will be more secure, and incorrect data will result in a helpful error.