Security Must Be Baked In, Not Painted On
A wave of hysteria, a brief surge in traffic, a burst of defacementsby now, it's a familiar story.A wave of hysteria, a brief surge in traffic, a burst of defacementsby 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 applicationsCommon 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 validatedthe 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.