Home » Data Protection » Application Security

In Depth

An introduction to the murky science of Web application security

By Simson Garfinkel

Page 3

Cross-site scripting attacks have shown up on websites where users can send each other messages (like LiveSpace and LinkedIn), websites where users can post content (like eBay and Wikipedia) and even websites that let users upload databases of links (because URLs can contain JavaScript). Seven in 10 websites are vulnerable to this attack, Grossman says.

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.

Platform Diving

From his vantage point at WhiteHat, Grossman has seen several organizations migrate websites from Microsoft’s original ASP to ASP.NET. “ASP classic, the first generation of ASP websites, are generally riddled with vulnerabilities,” he says. But when these organizations rewrote their applications using ASP.NET, suddenly their applications improved tremendously securitywise. “Same developers, two different frameworks. It wasn’t an education problem, it was a technology problem.”

The newer platforms are more secure than the old ones because the framework provides native secure libraries and APIs for account management, log-in/log-out, session handling, input validation and so on. It’s also important for a company to standardize on a single application development system. That way the company can build up in-house expertise, rather than approaching each new project like a novice.

Other companies have significant problems with process. For example, WhiteHat’s scanner will sometimes find a vulnerability the first time the site is scanned but not find it the second time. “Our systems figured they fixed it and closed the ticket.” But on a third scan the vulnerability sometimes comes back.

In a case like this, WhiteHat will call the customer. The developers look at their Web servers and say the vulnerability doesn’t exist. And indeed, on some scans the vulnerability is there, and on some it isn’t!

“We call it vulnerability clapping,” explains Grossman. “Many websites have load-balanced systems” behind a single URL. Each of these systems is supposed to be running exactly the same code, but sometimes they aren’t. “Some systems will be hot-fixed, and some won’t,” he says. These bugs are very hard to find because they require customers to examine each of their supposedly “identical” Web servers for differences.