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
