Preventing SQL Injection Attacks in Stored Procedures

Alex HertzChris DaielloCAP6135 Dr. Cliff ZouUniversity of Central FloridaMarch 19, 2009

Research PaperPublication

◦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 AttackTargets 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 AttackThere 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.

MotivationThe 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.

MotivationAccording 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 ProceduresStored 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

ExampleConsider 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.

ExampleFor 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.

ExampleA 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.

ProposalThis paper proposes a technique

designed to defend against attacks directed at stored procedures.◦Static application code analysis

Stored procedure parser

◦Runtime validation

ProposalThe 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 PhaseA parser is used to pre-process

and identify specific SQL statements in the EXEC() call for runtime analysis.

Runtime PhaseThe technique monitors all

dynamically-generated 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

ProposalThe 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-GraphOnly 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 ValidationBefore 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 IntentionsWe 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