SQL Injection Attacks and Defense - 2009

Platform-Level Defenses • Chapter 9 391
For PHP Web applications, you can leverage the auto_ prepend_ file and auto_append_ file
configuration directives in the php.ini file. These directives point to PHP files that will be
executed before and after the execution of every PHP script that is requested. The added-in
logic would loop through the various HTTP request collections (querystring, POST,
cookies, headers, etc.) and validate and/or log as necessary.
An alternative for both PHP and classic ASP applications is to use include files.
This requires code modification in the form of adding include directives on every application
page. Similarly, the included logic would loop through the various HTTP request collections
and validate and/or log as necessary.
Filtering Web Service Messages
The intercepting filter pattern is also easy to apply to XML Web Services with custom input
and output filters. An input filter could perform validation of method parameters and log
SQL injection attempts. You also could use an output filter to suppress error details, such as
those that often leak out in the faultstring of the Soap Fault message. The .NET Web Services
and Apache Axis platforms provide mechanisms for filtering inbound and outbound messages.
ModSecurity can also handle inbound XML messages to perform validation and logging
with the XML TARGET. Validation can be performed with XPATH queries or against a
schema or document type definition (DTD) file. Commercial XML firewalls can also be
considered, although they are typically network appliances and likely overkill if you are just
looking for SQL injection protection.
Non-Editable versus
Editable Input Protection
Almost every filter implementation employs blacklist protection, whereas whitelist validation,
which is much more powerful and effective against SQL injection, is less prevalent and often
complex to configure. This is likely because defining an exact match (i.e., whitelist) for every
request parameter is a daunting task, even if a learning mode is available. This is especially
true for inputs that except free-form text, such as textboxes.
Another input validation strategy to consider is classifying application inputs as
editable and non-editable, and locking down the non-editable inputs so that they cannot
be manipulated. Non-editable inputs are those that end users do not need to modify
directly—hidden form fields, URIs and querystring parameters, cookies, etc. The theory
behind the strategy is that the application should permit users to perform only those
actions that the user interface has presented to them. The idea is to leverage HTTP
responses at runtime to identify all legitimate requests (forms and links), collect the state
of each possible request, and then validate subsequent requests against the stored state
information. For many applications, non-editable inputs are the majority of input accepted
by an application. Therefore, if you can lock these down automatically at runtime, you can