SQL Injection Attacks and Defense - 2009

386 Chapter 9 • Platform-Level Defenses
ModSecurity and WAFs in general, we’re going to look at some solutions that could be
considered a WAF but are not as robust. However, they can be just as effective depending on
the scenario, and they can be potentially cheaper in cost and resource requirements to deploy.
Intercepting Filters
Most WAFs implement the Intercepting Filter pattern or include one or more implementations
in their overall architecture. Filters are a series of independent modules that you can chain
together to perform processing before and after the core processing of a requested resource (Web
page, URL, script, etc.). Filters do not have explicit dependencies on each other; this allows you
to add new filters without affecting existing filters. This modularity makes filters reusable across
applications. You can add filters to applications at deployment when implemented as a Web
server plug-in or when activated dynamically within an application configuration file.
Filters are ideal for performing centralized, repeatable tasks across requests and responses
that are loosely coupled with core application logic. They are also good for security functions
such as input validation, request/response logging, and transforming outgoing responses.
In the next two sections, we’re going to look at two common filter implementations:
Web server plug-ins and application framework modules. You can use both of them for
runtime SQL injection protection. Figure 9.7 shows where each is executed as the HTTP
request and response passes to/from the Web browser.
Figure 9.7 Diagram Depicting
Web Server and Application Filters
Web Server Filters
You can implement filters as Web server modules/plug-ins, which extend the core request
and response handling application program interface (API) of the Web server platform.
Basically, requests and responses handled by the Web server pass through a series of phases,