Network firewalls provide network layer access control and attack protection services. They have been uniformly deployed at the network perimeter and in front of critical internal enterprise resources – such as Web applications. As a component of overall Web application security architecture, network firewalls provide necessary protection against network-layer attacks. They also provide a barrier against the spread of worms from employee desktops to internal Web servers. While network firewalls prevent network-layer attacks and worm propagation, firewalls must allow all HTTP and HTTPS traffic to Web servers. Over time, the hacking community has learned to use this fact to their advantage by embedding attacks into Web traffic. Code Red and Nimda are examples of Web worms that easily traverse network firewalls via HTTP protocol-compliant communications.
Similarly, SQL injection and cross-site scripting represent two targeted Web application attacks (among many) that are ignored by network firewalls since they comply with network and HTTP protocols. As long as attacks are carried out via commonly allowed application protocols, network firewalls are ineffective.
The broader security industry has responded to the need for a deeper understanding of application layer behavior with intrusion prevention systems (IPS). IPSs look at the contents of a packet’s payload and compare it to a list of known attacks (signatures or other defenses) derived from documented vulnerabilities in commercial software. IPS technology may also enforce protocol restrictions to protect against known protocol related vulnerabilities in commercial software. Since virtually all worms are based on known software vulnerabilities, IPS can be an effective worm defense and therefore a useful component of a comprehensive Web application security architecture.
Unfortunately, IPSs are ineffective against targeted Web application attacks targeting unknown vulnerabilities in custom code. Since the vulnerabilities are unknown, no signatures are available.
Monitoring only (“sniffer”) products do not ensure complete protection from Web application attacks. Because they are deployed out of line, these products may not block every attack that has been detected. Usually, these products use a TCP reset for blocking attacks. In some cases, the latency involved in sending the reset after the attack is detected allows certain attacks to reach the victim. Hence, monitoring only solutions can only provide “best effort” protection for Web applications.
Web Application Vulnerability (AV) Scanners are tools used to automatically scan Web applications for potential vulnerabilities. Unfortunately, many vulnerabilities are only discovered during production run-time. Often, the application developers and the IT department are at odds, because while these vulnerability scanning tools enable visibility into application vulnerabilities, they do not alleviate or help reduce the time to production.
Typically, there are multiple cycles of scanning, code fixes and testing with unscheduled “rush” fixes that are costly and potentially disruptive.
While code review is a good idea, and is consistent with coding best practices, code review projects can entail significant ongoing personnel costs, lost of application deployment flexibility and resource allocation issues.
In addition, considering that applications change frequently, there may be multiple code review and code fix-testing cycles for every application product release and this often implies the need for emergency fix and test cycles. Furthermore, if an organization is using third-party or legacy applications, the source code often will not be easily available or easily understood which makes the likelihood of quickly fixing the discovered vulnerabilities very low.