7July_01_2008 Preventing SQL Injection Attacks in Stored Procedures
Preventing SQL Injection Attacks in Stored procedures

"In this paper, we propose a novel technique to defend
against the attacks targeted at stored procedures. This technique
combines static application code analysis with runtime
validation to eliminate the occurrence of such attacks.
In the static part, we design a stored procedure parser, and
for any SQL statement which depends on user inputs, we use
this parser to instrument the necessary statements in order
to compare the original SQL statement structure to that including
user inputs. The deployment of this technique can
be automated and used on a need-only basis. We also provide
a preliminary evaluation of the results of the technique
proposed, as performed on several stored procedures in the
SQL Server 2005 database."

"We propose an SQL-Injection Attack prevention technique
here that addresses all types of SQLIAs, as discussed in previous
sections. The technique works by combining static
analysis with runtime validation. The basis of such a technique
is that the control flow graph of the stored procedures
can be represented as an SQL-graph which indicates what
user inputs the dynamically built SQL statements depend
on. By using an SQL-graph, we reduce the set of SQL statements
we need to verify, by looking at only a small subset
of all the SQL statements in the stored procedure at runtime.
During runtime, we retrieve a Finite State Automaton(FSA)
from the EXEC(@SQL) procedure call and check the SQL
statement with inclusion of user inputs for compliance, flagging
them safe or unsafe."

The concept of an SQL-graph is used to reduce the runtime
scanning overhead by restricting the number of queries that
need to be scanned along any execution path that is taken
in the stored procedure. SQL queries that do not use user
inputs are not included in the SQL-graph. Only the SQL
queries that are exposed to the user inputs in some form
or the other (string manipulations included) are included
in the SQL-graph representation. The choice of such a
representation and the resulting benefits in terms of runtime
overhead would be explained as part of Runtime Validation.

Figure 1. SQL-graph Representation
The SQL-graph in Fig. 1 represents 4 different SQL queries
(EXEC statement hotspots) in the stored procedure as
nodes within a logical boundary, and 3 different user inputs
as being outside the logical boundary. If a particular user
input (I) is used in a SQL query (Q), the relationship (R)
between the two nodes is indicated by an undirected link
between the 2 nodes. We now define dependencies (D) in
the SQL-graph as links that point from one SQL query to
another SQL query such that the user inputs used by the
former is a proper superset of the user inputs used by the
latter.