SQL Injection

Explanations, Background, &

Recommendations

Michael Anderson
Enterprise Architecture Services
April 2006
SQL Injection - Introduction

 SQL Injection is a common attack mechanism in web and client/server applications

 The problem is not unique to any DBMS - Microsoft SQL Server; DB2, Oracle, and
others are equally affected
 The problem is not tied to a given application development language (i.e. Java, VB,
C++), or to an application platform (Web, Desktop, etc.)
 Utilizing "Stored Procedures" are not enough to avoid the problem!

Enterprise Architecture Services February 1, 2011 Page: 2

SQL Injection - Example

 Assume an application (web or even just a client/server app) prompts for a user
input value (we'll use name)
 As part of the application, a SQL string is constructed similar to the following:
 String sql = “select * from Products where ProductName = '” + name + “'”
 Think about what happens if someone enters the following as the value for name:
 John
 A' or 1=1--

Enterprise Architecture Services February 1, 2011 Page: 3

SQL Injection - Example

 The results of the last input would be the following query passed into the database:
 select * from Products where ProductName = 'A' or 1=1--'
 This would result in all values being returned from Products, obviously not what we
want!
 What about the following values for name:
 A'; delete from Products;--
 A'; drop table Products;--
 A'; exec master..xp_cmdshell 'dir';--

Enterprise Architecture Services February 1, 2011 Page: 4

SQL Injection - Example

 The “attacker” does not even need to know the structure of the database prior,
almost all of this can be discovered with simple techniques (assuming that database
errors are returned to the user)
 Having can be used to determine the columns (and thus tables) being
used
 Sum can be used to determine field types
 Things like @@version can provide system information

Enterprise Architecture Services February 1, 2011 Page: 5

SQL Injection - Integer

 For anyone thinking single quotes are the problem, think again! What about the
following query (where id is numeric):
 String sql = “select * from Products where ProductId = ” + id
 The same attack still works with any of the following:
 5 or 1=1--
 5; delete from Products;--
 5; drop table Products;--
 5; exec master..xp_cmdshell 'dir';--

Enterprise Architecture Services February 1, 2011 Page: 6

SQL Injection – Stored Procedures

 “Won't using Stored Procedures solve this?”

 Think about the following scenario:
 sp_getProductById requires an int parameter
 String sql = “exec sp_getProductById ” + id
 Since the SQL string is still being created prior to calling the stored procedure, we
are still at risk

Enterprise Architecture Services February 1, 2011 Page: 7

SQL Injection – Stored Procedures

 If proper application programming techniques are used, the call would look more like
the following:
 CallableStatement cs = connection.prepareCall(“{call sp_getProductById(?)}”);
 cs.setString(1, id);
 cs.execute();
 By using better application programming techniques, combined with better database
programming techniques, we've solved the problem! Haven't we?

Enterprise Architecture Services February 1, 2011 Page: 8

SQL Injection – Dynamic SQL

 It is already good practice to utilize dynamic SQL sparingly, this is for both security
concerns, and for performance (i.e. caching)
 What happens if the Stored Procedure is itself utilizing dynamic SQL?
 A good example of this is the stored procedure being evaluated for
returning a dynamic result set of translated labels
 Moving the problem to within the stored procedure does not remove the problem!
 Without eliminating all use of dynamic SQL, we are still at risk

Enterprise Architecture Services February 1, 2011 Page: 9

SQL Injection – Problem Statement

 So we can say the problem isn't solved by:

 Escaping single quoted values
 Using integer (i.e. Non-text) values
 Using stored procedures
 Eliminating Dynamic SQL*
 Masking error values from users
 We prefer to think of the problem as the following:
Unvalidated user input will lead to trouble, including SQL Injection and Buffer
Overrun's to name a few.

Enterprise Architecture Services February 1, 2011 Page: 10

SQL Injection – Recommendations
 Validate all user input
 Bench Check with others for any type of input that is utilized within store procedures or
SQL, including things like
 Check for proper data type
 Check for proper (or reasonable) data length
 Only allow for only appropriate input
 Harden systems, including things like
 Remove unneeded “features” (i.e. xp_cmdshell)
 Use of accounts with limited rights
 Give preference to stored procedures
 Keep use of dynamic SQL to absolute minimum
 when used, harden for all possible attacks
 Bind parameters when calling stored procs

Enterprise Architecture Services February 1, 2011 Page: 11

SQL Injection – Next Steps
 Educate & Communicate
 Present this topic to your individual areas

Enterprise Architecture Services February 1, 2011 Page: 12