Preventing SQL Injection Attacks in Stored Procedures

1. Preventing SQL Injection Attacks in Stored Procedures Alex Hertz Chris Daiello CAP6135Dr. Cliff Zou University of Central Florida March 19, 2009

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

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

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

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

6. Motivation • According to the Imperva Application DefenceCenter, 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.

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

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

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

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

11. Proposal • This paper proposes a technique designed to defend against attacks directed at stored procedures. • Static application code analysis • Stored procedure parser • Runtime validation

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

13. Offline Phase • A parser is used to pre-process and identify specific SQL statements in the EXEC() call for runtime analysis.

14. Runtime Phase • The 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.

15. Runtime Phase • If an attack is detected • The malicious statement is prevented from accessing the database • Details about the attack are provided

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

17. SQL-Graph

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

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

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