Preventing SQL Injection
Attacks in Stored Procedures
Alex Hertz
Chris Daiello
CAP6135
Dr. Cliff Zou
University of Central Florida
March 19, 2009
Research Paper

Publication
◦ Australian Software Engineering Conference,
2006. (ASWEC 2006)

Authors
◦ Ke Wei
 Dept. of Electrical and Computer Engineering at Iowa
State University
◦ M. Muthuprasanna
 Dept. of Electrical and Computer Engineering at Iowa
State University
◦ Suraj Kothari
 Dept. of Electrical and Computer Engineering at Iowa
State University
SQL Injection Attack
Targets interactive web applications that
employ database services.
 These applications form SQL statements
from user input.
 An attacker can place malicious SQL
statements into the input

◦ Can gain access to vital database information
◦ Can use this vulnerability as an IP/Port
scanner of the internal network
SQL Injection Attack

There has been extensive research in the
field of guarding against this vulnerability
in the application layer.
◦ This can be done by examining dynamic SQL
query semantics at runtime.

There has been little research on the
vulnerabilities that exist in stored
procedures, which are at the database
layer.
Motivation
The growing popularity of the Internet in
the past decade has made it something we
rely on for everyday activities.
 The applications and their underlying
databases hold confidential and sensitive
data.
 Downtime can easily result in millions of
dollars damages.
 These databases have security flaws that
must be protected against targeted attacks.

Motivation
According to the Imperva Application
Defence Center, 92% of all web
applications are vulnerable to some form
of malicious intrusion.
 Vulnerabilities that lead to SQL Injection
attacks are well understood.
 However, there is still a lack of effective
techniques for detecting and preventing
them.

Stored Procedures

Stored procedures are an important part
of relational database systems
◦ They add an extra layer of abstraction into
the design of a software system
◦ This extra layer can hide some of the design
secrets from potentially malicious users
 i.e. Definitions of tables

The use of dynamic SQL queries can be
useful, but can pose an SQL injection
vulnerability
Example
Consider a stored procedure that is
called with a username and a password
 This procedure uses that user input to
dynamically generate an SQL statement
to be executed using the EXEC(@SQL)
system function.

Example

For instance, after calling the procedure
with the values “testuser” and
“testpasswd” for the username and
password respectively, the procedure
would generate the following SQL query
◦ select PROFILE from EMPLOYEE where
NAME=‘testuser’ and PASSWD=‘testpasswd’

This statement would then be passed to
the EXEC() function.
Example
A user could also input “‘OR 1=1 --’” as
the username and “null” as the password
 The SQL query generated would look like

◦ select PROFILE from EMPLOYEE where
NAME=“OR 1=1 −−’ and PASS=‘null’
The characters “−−” will comment out
anything following them
 The query will be interpreted as a
tautology, thus always satisfied.

Proposal

This paper proposes a technique designed
to defend against attacks directed at
stored procedures.
◦ Static application code analysis
 Stored procedure parser
◦ Runtime validation
Proposal
The key intuition behind the technique
described in this paper is that an SQL
injection will alter the structure of an
SQL statement.
 An SQL injection can be identified by
detecting the difference in the structures.
 This is done in two phases

Offline Phase

A parser is used to pre-process and
identify specific SQL statements in the
EXEC() call for runtime analysis.
Runtime Phase
The technique monitors all dynamicallygenerated SQL queries associated with
the user input.
 The technique captures the original
structure of the SQL statement and
checks for compliance after inclusion of
the user inputs.

Runtime Phase

If an attack is detected
◦ The malicious statement is prevented from
accessing the database
◦ Details about the attack are provided
Proposal

The control flow graph of the stored
procedures can be represented as an
SQL-graph
◦ Indicates which user inputs the dynamically
built SQL statements depend on.

The control flow graph is extracted
during the static analysis phase.
SQL-Graph
SQL-Graph
Only EXEC() calls that depend on user
input need to be tested in this system.
 Other EXEC() calls can exist, but pose no
security threat if they do not take user
input.
 The concept of the SQL-graph is to
reduce the runtime overhead by
displaying dependencies between multiple
queries and inputs.

Runtime Validation
Before an EXEC() is called, the SQL
statement is sent into a the validation
function to determine if it is a valid
statement.
 This function will be able to detect

◦
◦
◦
◦
Tautologies
Addition SQL statements
Second-Order Injection
Other Injection attacks
Our Intentions

We intend to implement this technique
on our own system.
◦ Verify the validity of the algorithm

We will try to analyze the effectiveness
on newer database management systems
◦ The authors used SQL Server 2005

We will try to improve upon the author’s
algorithm