SQL Injection Attacks and Defense - 2009

Reviewing Code for SQL Injection • Chapter 3 97
and execute SQL statements (these are listed in detail in “Dangerous Functions” later in this
chapter). Once you have identified a sink, it may be very obvious that an SQL injection
vulnerability exists. However, in most cases you will have to dig a little deeper into the code
base to determine whether one exists. SQL injection vulnerabilities most commonly
occur when the Web application developer does not ensure that values received from a sink
source (a method from where the tainted data originates, such as a Web form, cookie,
input parameter, etc.) are validated before passing them to SQL queries that will be executed
on a database server. The following line of PHP code illustrates this:
$result = mysql_query("SELECT * FROM table WHERE column ='$_GET["param"]'");
The preceding code is vulnerable to SQL injection because user input is passed directly
to a dynamically constructed SQL statement and is executed without first being validated.
In most cases, identifying a function that is used to create and execute SQL statements
will not be the end of the process, as it may not be possible from the line of code to easily
identify the presence of a vulnerability. For example, the line of PHP code that follows is
potentially vulnerable, but you can’t be sure, as you do not know whether the $param
variable is tainted or whether it is validated before it is passed to the function:
$result = mysql_query("SELECT * FROM table WHERE column = '$param'");
To make an informed decision as to whether a vulnerability exists, you need to trace the
variable to its origin and follow its flow through the application. To do this you need to
identify the entry points into the application (the sink source), and search the source code to
identify at what point the $param variable is assigned a value. You are trying to identify a line
of PHP code that is similar to the one that follows:
$param = $_GET["param"];
The preceding line assigns the user-controlled data to the $param variable.
Once an entry point is identified, it is important to trace the input to discover where
and how the data is used. You can do this by tracing the execution flow. If the trace found
the following two lines of PHP code, you could safely deduce that the application was
vulnerable to SQL injection within the user-controlled parameter $param:
$param = $_GET["param"];
$result = mysql_query("SELECT * FROM table WHERE field = '$param'");
The preceding code is vulnerable to SQL injection because a tainted variable ($param)
is passed directly to a dynamically constructed SQL statement (sink) and is executed. If the
trace found the following three lines of PHP code, you could also safely deduce that the
application was vulnerable to SQL injection; however, a limit is imposed on the length of
the input. This means it may or may not be possible to effectively exploit the issue. You need
to start tracing the $limit variable to see exactly how much space is available for an injection: