Guide to SQL Injection

From OWASP
Revision as of 19:46, 9 August 2008 by Jeff Williams (Talk | contribs)

Jump to: navigation, search

Contents

Overview

SQL injection is a security vulnerability that occurs in the persistence/database layer of a web application. This vulnerability is derived from the incorrect escaping of variables embedded in SQL statements. It is in fact an instance of a more general class of vulnerabilities based on poor input validation and bad design that can occur whenever one programming or scripting language is embedded inside another.

Threat Modeling

  • SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrator of the database server.
  • SQL Injection is very common with PHP and ASP applications due to the prevalence of older functional interfaces. Due to the nature of programmatic interfaces available, Java EE and ASP.NET applications are less likely to have easily exploited SQL injections.
  • The severity of SQL Injection attacks is limited by the attacker’s skill and imagination, and to a lesser extent, defense in depth countermeasures, such as low privilege connections to the database server and so on. In general, consider SQL Injection a high impact severity.

Related Security Activities

Description of SQL Injection Vulnerabilities

See the OWASP article on SQL Injection Vulnerabilities.

How to Review Code for SQL Injection Vulnerabilities

See the OWASP Code Review Guide article on how to Review Code for SQL Injection Vulnerabilities.

How to Test for SQL Injection Vulnerabilities

See the OWASP Testing Guide article on how to Test for SQL Injection Vulnerabilities.

How to Avoid SQL Injection Vulnerabilities

There are two complementary and successful methods of mitigating SQL Injection attacks:

  • Parameterized queries using bound, typed parameters
  • Careful use of parameterized stored procedures.

Parameterized queries are the easiest to adopt, and work in fairly similar ways among most web technologies in use today, including:

  • Java EE
  • .NET
  • PHP

Parameterized Queries with Bound Parameters

Parameterized queries keep the query and data separate through the use of placeholders known as "bound" parameters. For example in Java, this looks like this:

"select * from table where columna=? and columnb=?"

The developer must then set values for the two ? placeholders. Note that using this syntax without actually using the placeholders and setting values provides no protection against SQL injection.

Parameterized Stored Procedures

The use of parameterized stored procedures is an effective mechanism to avoid most forms of SQL Injection. In combination with parameterized bound queries, it is very unlikely that SQL injection will occur within your application. However, there are a number of caveats to bear in mind:

  • Use of dynamic code execution features will allow SQL Injection:

create proc VulnerableDynamicSQL(@userName nvarchar(25)) as

 declare @sql nvarchar(255)
 set @sql = 'select * from users where UserName =  
   + @userName + '
 exec sp_executesql @sql

(MS SQL example from http://dotnetjunkies.com/WebLog/chris.taylor/archive/2004/10/13/28370.aspx)

The above example still allows SQL Injection as it allows dynamic injection of arbitrary string data. This gotchya is also true of Java / PL/SQL and MySQL's stored procedure support.

Least privilege connections

Always use accounts with the minimum privilege necessary for the application at hand, never “sa”, “dba”, “admin”, or the equivalent.

WARNING: Escaping table names

No SQL Injection mitigation or escaping allows the safe escaping of table names. This seems to be a common issue with PHP forum software.

$tablename = mysql_real_escape_string($tablename)

is simply not safe and cannot be made so. In general:

  • Avoid using dynamic table names if at all possible.
  • If you have to use dynamic table names, do not accept them from the user if at all possible.
  • If you have to allow dynamic user choice of table names, ONLY use whitelists of acceptable characters for table names and enforce table name length limits. In particular, many database systems have a wide range of unacceptable characters and these change between major releases.