If you listen to the prophets of the information age,1.1 everything is going to be Internet-enabled Real Soon Now. And even though the eBusiness sector is shrinking, everyone is trying to get a slice of the Internet pie. Of course, all those eProducts are awfully secure. But if you watch buggy and insecure web applications being paraded on bugtraq almost every day, it makes you wonder whether this whole eCommerce thing isn't headed to become Shoplifter's Paradise.
And while consumers haven't really swallowed the eCommerce pill yet, buzzword bozos are throwing the next bogosity at us: m-commerce; m meaning mobile. Just like eCommerce, except you do it via your mobile phones. Enabling just the digital equivalent of pickpockets?
Okay, I admit I'm being sarcastic here, and maybe not entirely fair.
Of course, eCommerce platforms, and web services in general, are not the only applications where security is an issue. Ever played one of those networked multiplayer computer games? Ever wondered whether they are secure? Web browsers? Mail readers? It may not really come as a surprise that in each of these classes of applications, vulnerabilities have been found that allowed remote attackers to run arbitrary commands on the victim's computer.
Software security bugs cannot just be attributed to negligence or ignorance. Even skilled software engineers who consider software security fairly important do make mistakes. We, as programmers, tend to develop a sort of blind spot when looking at our own code. If you're a programmer, you will probably know those mythical bug hunts: you spend several days debugging a mysterious crash in your application, and it turns out that all the time you've been staring at the code, the bug has been staring right back at you. But you didn't notice it because you were looking through the code, seeing the concept behind it. Programmers are good at conceptual thinking. Compilers, on the other hand, are very bad at it; narrow-mindedly they will translate the code you wrote, statement by statement.
The same thing is true of security bugs. But the difference is that ordinary bugs are easily recognizable, because they're quite annoying. With your everyday bug, the application just doesn't do what you want it to do. It crashes in the middle of some operation, or it runs incredibly slow, or trashes your home directory. Security bugs, on the other hand, are less obvious. They aren't noticeable until you look at the application with a hostile intent.
Consider an application that extracts and address from an HTML web form: name, street, ZIP code, city, etc, and copies each item to a 50 byte buffer. For virtually all users in the Western hemisphere, this program will work just fine, and the fact that user provided data can overflow a buffer will go unnoticed. Except by inhabitants of a few obscure Welsh towns with a name longer than fifty characters, and nasty persons intent on making the application crash.
However, for security critical applications, writing past the end of memory buffers is usually a dangerous thing. These bugs can often be exploited to gain access to the server the application is running on.
This example illustrates why security bugs are different. Most of the time, they do not show up during routine testing. In order to find them, you have to look at your code from a cracker's perspective, with the intention of finding a glitch by which you can break it. These bugs do not jump at you, you really have to sit down wanting to find them.
Unfortunately, spotting security bugs and avoiding them is still something of a black art. Basically, it is impossible to find them if you don't know what you're looking for. If you know all the standard techniques by which crackers try to subvert an application, you can go through the code looking for vulnerable spots.1.2