Web applications are the latest gold mine for criminals bent on gathering valuable corporate and consumer data. SQL injections, cross-site scripting vulnerabilities, forceful browsing, input validation exploits and cookie manipulation are rampant and successful against a number of high-profile, well-secured, brand name Web sites (see below). In fact, 48 percent of all new vulnerabilities exposed in the last half of 2004 were in Web applications, up from 39 percent in the first half of that same year, according to Symantec — making Web applications the number one vector for attackers.

Here's a small sampling of Web application attacks and vulnerabilities reported over the past 18 months:

• SQL injections, which were exploited to compromise the customer database at Tiffany.com; and, in a separate case, to expose 500,000 Petco customer credit cards.
• Cross-site scripting vulnerabilities, as when Google G-Mail accounts were rendered accessible without authentication.
• Forceful browsing, used to expose the police files in the State of Minnesota; and, separately, to expose Paymaxx's customer tax identification information.
• Cookie manipulation or cookie poisoning, as evidenced by Gateway Computer when customer order information was exposed, including credit card CVV and expire dates; FTD.com was affected similarly by same attack method.
• URL parameter tampering, to which Microsoft Asp.net, Victoria's Secret, Morgan Stanley were all vulnerable in the recent past.

Why are these problems on the rise, particularly after all these years we've known about common vulnerabilities that can occur in poorly-planned fields, and the recent focus on secure application development, such as Microsoft's Trustworthy Computing secure development program? The answer is three-fold, says Daniel Cuthbert, co-founder of the Open Web Application Security Project: Too little time and lack of education among developers, accompanied by a misguided trust that network-layer security will protect the application from attempts to exploit its inherent vulnerabilities.

In today's short development cycles, developers are rushed just to write the applications and do a cursory de-bug, he continues. Time to stop and think critically about how the functional fields in the application can be manipulated and testing those hypotheses is a luxury most developers don't have.

While there are plenty of books out there on developing secure Web applications, the second part of the problem is still a lack of security-savvy developers. The vast majority of developers, he says, still don't understand that the applications can go wrong anywhere the application interacts with the human.

"Developers don't understand that they're building applications without any protection against logical vulnerabilities such as input validation attacks, SQL injections, authorization and authentication exploitation and session attacks," says Cuthbert, who also teaches secure application development at Vigilar's Intense School, headquartered in Atlanta.

Lacking the time and knowledge to turn out Web applications that are secure from the onset, developers trust, erroneously, that security slapped on after the fact — network firewalls and intrusion detection — will protect them, Cuthbert says. But even the new Web application firewalls coming to market are only partially successful in distinguishing when a user is attempting to manipulate an application, says Jeremiah Grossman, CTO of White Hat Technologies, a Santa Clara, Calif.-based managed vulnerability scanning service provider.

"Once I came across a vulnerability in an online auction application. When you put in a bad password, it locks you out of the system. I put in a bad password for a competing bidder, and it locked him out of the bidding," Grossman explains.

Furthermore, defining parameters of what constitutes legitimate and illegitimate user behavior needed to program firewall rules consumes a lot of time, and requires intimate knowledge of the application fields, functions, and parameters that only the developers know. Taking such a backward approach to application security triples your costs by spreading it out like this. And that's not to mention the cost to damaged reputation, network security response, and application repair.

"If you need to justify security in a development project," says Weinschenk, "tell your superior that fixing a bug costs far more than protecting in advance."