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.

Yet another vulnerability is the cross-site scripting attack. These attacks are made possible when a Web application accepts a message from one user and displays it to another user without proper filtering. This is a problem because messages on the Web can contain JavaScript, and JavaScript is the programming language in which the client’s half of a Web application is written. With a cross-site scripting attack, one user can literally take over a second user’s account just by sending that user a message and having him read it.