SQL Injection Attacks and Defense - 2009

342 Chapter 8 • Code-Level Defenses
Introduction
In Chapters 4 through 7, we focused on ways to compromise SQL injection. But how
do we fix it? And how do we prevent SQL injection in our applications going forward?
Whether you’re a developer with an application that is vulnerable to SQL injection,
or whether you’re a security professional who needs to advise your client, there are
a reasonably small number of things that you can do at the code level to reduce or
eliminate the threat of SQL injection.
This chapter covers several large areas of secure coding behavior as it relates to SQL
injection. First we’ll discuss alternatives to dynamic string building when utilizing SQL in
an application. Then we’ll discuss different strategies regarding validation of input received
from the user, and potentially from elsewhere. Closely related to input validation is output
encoding, which is also an important part of the arsenal of defensive techniques that you
should consider for deployment. And directly related to input validation, we’ll cover
canonicalization of data so that you know the data you are operating on is the data you
expected. Last but not least, we’ll discuss design-level considerations and resources you can
use to promote secure applications.
You should not consider the topics we’ll discuss in this chapter to be techniques to
implement in isolation; rather, they’re techniques you should normally implement as part of a
defense-in-depth strategy. This follows the concept that you do not rely on any single control
to address a threat, and where possible, you have additional controls in place in case one of
these controls fails. Therefore, it is likely that you’ll need to implement more than one of the
techniques we’ll cover in this chapter to fully secure an application against SQL injection.
Using Parameterized Statements
As we discussed in previous chapters, one of the root causes of SQL injection is the creation
of SQL queries as strings that are then sent to the database for execution. This behavior,
commonly known as dynamic string building or dynamic SQL, is one of the primary causes
of an application being vulnerable to SQL injection.
As a more secure alternative to dynamic string building, most modern programming
languages and database access application program interfaces (APIs) allow you to provide
parameters to an SQL query through the use of placeholders, or bind variables, instead of
working directly with the user input. Commonly known as parameterized statements,
these are a safer alternative that can avoid or solve many of the common SQL injection
issues you will see within an application, and you can use them in most common situations
to replace an existing dynamic query. They also have the advantage of being very efficient
on modern databases, as the database can optimize the query based on the supplied prepared
statement, increasing the performance of subsequent queries.