SQL Injection Attacks and Defense - 2009

Reviewing Code for SQL Injection • Chapter 3 101
cmd.Parameters.Add(new SqlParameter("@input",
request.getParameter("input")));
SqlDataReader rdr = cmd.ExecuteReader();
// a dynamically executed sql stored procedure in Java
CallableStatement cs = con.prepareCall("{call SP_ StoredProcedure
request.getParameter("input")}");
string output = cs.executeUpdate();
The preceding lines of code all execute and pass user-controlled tainted data as
parameters to SQL stored procedures. If the stored procedures are incorrectly constructed
in a similar fashion to the examples presented previously, an exploitable SQL injection
vulnerability may exist. When reviewing source code, not only is it important to identify
vulnerabilities in the application source code, but in cases where stored procedures are in
use, you may have to review the SQL code of stored procedures as well. The example source
code given in this section should be sufficient to help you understand how developers produce
code that is vulnerable to SQL injection. However, the examples given are not extensive;
each programming language offers a number of different ways to construct and execute
SQL statements, and you need to be familiar with all of them (I list them in detail for C#,
PHP, and Java in “Dangerous Functions” later in this chapter).
To make a definitive claim that a vulnerability exists in the code base, it is necessary to
identify the application’s entry points (sink sources) to ensure that the user-controlled input
can be used to smuggle in SQL statements. To achieve this, you need to be familiar with how
user-controllable input gets into the application. Again, each programming language offers
a number of different ways to obtain user input. The most common method of taking in
user input is by using an HTML form. The following HTML code illustrates how a Web
form is created:
In HTML, you can specify two different submission methods for a form: You can use
either the get or the post method. You specify the method inside a FORM element, using
the METHOD attribute. The difference between the get method and the post method is
primarily defined in terms of form data encoding. The preceding form uses the get
method; this means the Web browser will encode the form data within the URL. If the
form used the post method, it would mean the form data would appear within a message
body. If you were to submit the preceding form with the post method, you would see
“http://www.victim.com/process_input.php” in the address bar. If you were to submit the
information via the get method, you would see the address bar change to “http://www.victim.
com/process_input.php?foo=input&bar=input”.