Built in, not bolted on
Because you can't protect Web applications with a firewall, the only way to protect them is by building the protection into the application itself. This is harder than it sounds, because every Web application has two parts: the part running on your servers and the part that's running inside your customer's Web browser. Adding protection to the Web application means that the developer needs to develop a program where one half doesn't trust the other half. This is a hard idea for most developers to get their heads around.
One common vulnerability on the Web today is something called the predictable identifier vulnerability. What typically happens is part of the website is set up to display information whenever a Web browser asks for a piece of information using a certain identifier. For example, one URL might display a check image when it is provided with an account number and a check number. The developer might think that this doesn't present a problem because anybody who knows the account number and the check number should be entitled to see that check image. The problem is that check numbers are predictable--they are issued sequentially. So just by trying different check numbers, a person who received one check from a payee could access all of the other checks that the payee had written.
The predictable identifier vulnerability has shown up many ways over time. Years ago I remember one website that sent its customers a URL to view their receipts. The URL had a number in it. By incrementing the number, customers could see the receipts of other customers. And just a few months ago, WhiteHat's security engineers discovered a website in which users of the website's free services could access services that were available only to users with paid accounts. Overall, says Grossman, one in four websites that WhiteHat has tested are susceptible to this vulnerability.
Another common vulnerability is the so-called SQL Injection Attack. These vulnerabilities arise when information provided by the website's user isn't properly validated before being used to create a query that's written in the Structured Query Language, the interface language used by most of today's database systems. SQL injection attacks can be devastating to both customer privacy and the integrity of financial information. WhiteHat has found that one in five websites is vulnerable to this kind of attack.
There are two ways to address systematic problems like predictable IDs, SQL injection and cross-site scripting. The first is developer training--teach developers to write bug-free code. Grossman believes this is a best practice, but cautions that it won't have a significant impact for several years to come. The reason is that large companies that have hundreds of developers have a high turnover rate, so they will be playing catch-up for a while to come. Just one bug can render an entire website vulnerable.
The second security approach is to rewrite legacy Web applications with modern developer tools--tools that are less susceptible to these kinds of problems.