IT managers often find themselves in the position of the boy who stuck his finger in the dike—but theyre plugging system holes to prevent security floods. These holes will only increase in number as Web applications and Web services proliferate, but IT managers can provide more than stopgap security with a number of new tools and some best-practice measures.
Web applications—either internally developed or packaged—are often the weak link that crackers exploit to break into a site. Web-based vulnerabilities were exploited by both Nimda and Code Red, and Web application vulnerabilities were the downfall of eWEEK Labs first, second and fourth OpenHack security tests.
Although firewalls do a good job of protecting internal network resources from hostile network traffic in general, applications exposed over HTTP are wide open to all kinds of hostile attacks.
Complex, custom applications such as customer self-service sites are particularly in need of protection because they often create the dangerous combination of public accessibility and potential access to protected customer information.
The problem will grow in scope with the exposure of business logic (and related connected database resources) through Web service deployments because Web services are most often published using HTTP as a transport protocol. Web services also bypass existing front-end Web application input parameter checking, making it vital that input validation code be duplicated in the Web service itself.
With the wide variety and large number of externally facing Web applications deployed in the enterprise, its almost impossible to bulletproof every application and Web server.
Patching known problems is a must, of course, but doing so in a server farm environment takes time and testing. Finding security bugs in custom-developed Web application code is a painstaking and all-too-error-prone process, given HTTPs complete lack of input validation checking.
|
Security audits, authorized penetration testing, and the use of structured application testing tools and higher-level development frameworks all make a difference.
As we saw in last Octobers OpenHack test, however, even stringently audited Web application code can contain bugs. In that test, two cross-site scripting attacks succeeded because, out of the hundreds of parameters that were filtered for illegal input in our test Web application, two were not. An intrepid cracker found the untested parameters and exploited them.
A central pillar of strong security is an acknowledgment that packaged applications and custom code will contain security vulnerabilities, no matter how valiant the efforts to eliminate them. Thus, additional layers of protection must be deployed.
To this end, a new set of HTTP-specific firewalls is emerging to address the security mismatch between traditional port-level firewalls and the security demands of Web applications and Web services.
This is still an immature market overall. eWEEK Labs tests of the leading products in this category show that no one product does it all (see reviews). Weve seen considerable advancement in the state of the art just during the past six months, however, and we expect to see more of the same through the rest of this year.
As a group, these products white-list-defense philosophy and real-time HTTP request and parameter filtering make them extremely powerful tools for securing Web applications. We recommend their use for security-sensitive Web applications.
Its important to keep in mind, however, that while new classes of tools, such as Web application firewalls and trusted operating system add-ons, are emerging as important new defensive techniques, they only mitigate—and dont remove—the need for secure programming practices and server hardening. But with additional protection in place, attackers will have a significant new barrier to get around, and administrators will gain a potent tool for monitoring and protecting valuable data.
