eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
A wave of hysteria, a brief surge in traffic, a burst of defacements—by now, its a familiar story. The most recent chapter, of course, was written by the Code Red worm, which has swept through the Internet, infecting thousands of systems running unpatched versions of Microsofts IIS Web server software, including Microsofts own update site. Its only the latest in an increasing number of incidents involving bugs in commercial Web server software. In fact, so frequent are these incidents that, for many of the victims, just keeping up with the server software fixes seems to be too much to handle.
But, as annoying as such defacements are, in my opinion the more serious threat comes from security vulnerabilities in badly written home-grown Web applications—Common Gateway Interface scripts, server-side executables, active scripting and so forth. All too often, authentication methods are weak, session information is exposed, user input isnt properly validated—the possibilities are endless. These are the holes that are most likely to expose customer or business proprietary data. Whats more, they are harder to find and fix because theres no vendor to issue a patch, and, unfortunately, they are plentiful. Without adequate training, in-house or contract development teams may not even be aware of problems.
Why is Web application security so poor? Some Web site designers began their careers doing graphic design, not programming, and have little understanding of the security implications of their way-cool bells and whistles. At the same time, on the Web, traditional software life cycle steps are often compressed or omitted because of time pressures from marketing or product management departments. Instead of focusing on vulnerabilities, teams that are supposed to be doing quality assurance testing too often only look at usability and appearance.
Add to all that the fact that custom-developed applications tend to be found in just those areas where the need for security is greatest—health care and financial services. Health insurers and managed care providers are looking to the Internet as a way to reach more customers and reduce costs and turnaround time. Banks and credit unions want to offer more convenience with fewer tellers. In theory, this is a good thing. In practice, its often a bad thing, as we discovered at my company when our testing team was able to download thousands of records from the Web sites of our clients. Its an inconvenience if someone steals your credit card number; it can be a nightmare if the wrong person gets your medical records.
So much business is moving onto the Internet that we cant wait for evolution to produce better code (an approach that has failed in every other area of software development). Several consulting companies offer Web application security testing that you can use to gauge just how well your organization is doing. Or you can create your own in-house tiger team. Better still, address the issues before vulnerabilities make it into the code by making sure development teams receive training in how to write secure Web applications and that they keep up with current issues.
Remember, security should be baked in, not painted on. Security should be an integral part of your software life cycle process, beginning with design and continuing through development and testing.