Difference between revisions of "Guide to SQL Injection"

From OWASP
Jump to: navigation, search
 
(Related Security Activities)
Line 1: Line 1:
 
 
 
'''SQL Injection'''
 
'''SQL Injection'''
  
Line 14: Line 12:
  
 
==Related Security Activities==
 
==Related Security Activities==
TBD
+
 
 +
===Description of SQL Injection Vulnerabilities===
 +
 
 +
See the OWASP article on [[SQL Injection]] Vulnerabilities, and the references at the bottom of this page.
 +
 
 
===How to Test for SQL Injection Vulnerabilities?===
 
===How to Test for SQL Injection Vulnerabilities?===
  
Line 30: Line 32:
 
Parameterized queries are the easiest to adopt, and work in fairly similar ways among the three major technologies in use today:
 
Parameterized queries are the easiest to adopt, and work in fairly similar ways among the three major technologies in use today:
  
‘’PHP:’’
+
* PHP
 
+
* J2EE
‘’J2EE’’
+
* .NET
 
+
‘’ASP.NET’’
+
  
===Low privilege connections===
+
===Least privilege connections===
  
Always use low privilege connections, never “sa”, “admin”, or equivalent.  
+
Always use accounts with the minimum privilege necessary for the application at hand, never “sa”, “dba”, “admin”, or the equivalent.
  
 
===WARNING: Escaping table names===
 
===WARNING: Escaping table names===
Line 50: Line 50:
 
* Avoid using dynamic table names if at all possible.  
 
* 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 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.  
+
* 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.
  
 
== To learn more ==
 
== To learn more ==

Revision as of 23:24, 23 January 2007

SQL Injection

Overview

A SQL injection attack consists of insertion or "injection" of an SQL query via the input data from the client to the application.
A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. For an introduction to SQL Injection, please refer to the references at the bottom of the page.

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, J2EE 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, and the references at the bottom of this page.

How to Test for SQL Injection Vulnerabilities?

See the OWASP Testing Guide article on how to Test for 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 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 the three major technologies in use today:

  • PHP
  • J2EE
  • .NET

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.

To learn more

  • Link to Top 10 or other articles