12/01/2009 11:20:58 AM

This is a revision to an article published January 2008

At first glance, this statement must clearly be an oxymoron (think jumbo shrimp), and you might question the sanity of the folks at The Open Web Application Security Project (OWASP), who composed it. Web applications run on servers protected by Internet firewalls, correct? Partly.

Are You Inspecting Network or Web Traffic?

To make web applications accessible to anyone on the Internet, security administrators must allow web traffic to pass through a firewall. The application stream (HTTP and application data, for example) passes through most firewalls without inspection.

Are You Inspecting Web Traffic or Protecting Web Applications?

Even when firewalls do inspect web traffic, they don’t typically inspect secure (SSL) transactions, such as credit card-based transactions, intranet access, and certain database inquiries. SSL connections encrypt web traffic, from the user’s browser all the way to the secure web server, which prevents even “application aware” firewalls from inspecting web application traffic. (Note: certain organizations may proxy SSL traffic at an application firewall but the trust assertions implicit in such configurations are controversial and tricky).

Even when your organization employs one of the many forms of web application protection, these countermeasures, like their antimalware, antivirus gateway predecessors, largely protect against known vulnerabilities. Thus, measures you take to secure your web application code are quite often all that stand between your sensitive data and attackers.

Until recently, web application development hasn’t paid much attention to security, or more specifically, secure application-coding practices. In truth, few web developers are familiar with secure coding practices, certainly much less so than folks who develop code for firewalls specifically, and security systems in general. Savvy attackers understand this better than most organizations, and now try to penetrate an organization through its web presence. The front door’s unlocked, and no one’s watching…

Sizing Up the Problem

To appreciate just how much of a problem this poses, consider a few of the security measures that firewalls and other security systems provide:

• Protocol compliance, assures that improperly composed traffic cannot be used to compromise a system, deny or disrupt service.
• Authentication, assures that only users with valid credentials are permitted access to sensitive data and resources;
• Access control, assures that authenticated users only access systems and data they have been granted permission to use;
• Denial of service protection, assures that traffic flooding and other resource depletion attacks do not disrupt services.
• Unified threat management, measures to detect and block known and “sufficiently similar to suspect as” malicious code or an application level attack. 

If the firewall’s not examining HTTP, XML, URLs, and application protocols and data tunneled in HTTP, web applications must validate all input, not just protocol headers, to protect backend (e.g., database) and underlying operating systems from attack. If the firewall’s not enforcing authentication and access controls, then the web application must. Generally, web applications must make certain that any security measure web traffic bypasses is compensated for, in the application itself.

Application protection solutions are immensely appealing precisely because they claim to relieve web developers from the onerous task of writing secure applications. Like every security solution before them, application protection can complement but not entirely replace secure web application development. Every organization should become proactive in secure application development. Begin by having your developers learn how web applications are most often exploited. The best resource I’ve found online is the 2007 update to The OWASP Top Ten Most Critical Web Application Security Vulnerabilities, which identifies the most commonly exploited web programming flaws and configuration errors, explains how you can determine if your applications are vulnerable, and how you can protect yourself. I recommend you begin here.