A [[SQL injection]] attack consists of insertion or "injection" of a 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 as 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.

−

SQL injection is a security vulnerability that occurs in the persistence/database layer of a web application.

+

SQL injection attacks are a type of [[Top 10 2007-Injection Flaws | injection attack]], in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

−

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

==Threat Modeling==

Line 15:

Line 19:

===How to Avoid SQL Injection Vulnerabilities===

===How to Avoid SQL Injection Vulnerabilities===

−

See the [[:Category:OWASP Guide Project|OWASP Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.

+

See the [[:Category:OWASP Guide Project|OWASP Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.<br>

+

See the OWASP [[SQL Injection Prevention Cheat Sheet]].

−

===How to Avoid SQL Injection Vulnerabilities===

+

===How to Review Code for SQL Injection Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.

Line 23:

Line 28:

===How to Test for SQL Injection Vulnerabilities===

===How to Test for SQL Injection Vulnerabilities===

−

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection|Test for SQL Injection]] Vulnerabilities.

+

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities.

−

+

−

+

−

+

−

+

−

[[Category:Security Focus Area]]

+

−

__NOTOC__

+

−

+

−

+

−

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

+

−

SQL injection attacks are another instantiation of an [[Top 10 2007-Injection Flaws | injection attack]], in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

* Authentication: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.

+

* '''Authentication''': If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.

−

* Authorization: If authorization information is held in an SQL database, it may be possible to change this information through the successful exploitation of an [[Glossary#SQL Injection|SQL Injection]] vulnerability.

+

* '''Authorization''': If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a [[Glossary#SQL Injection|SQL Injection]] vulnerability.

−

+

−

* Integrity: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with an [[Glossary#SQL Injection|SQL Injection]] attack.

+

+

* '''Integrity''': Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a [[Glossary#SQL Injection|SQL Injection]] attack.

+

== Risk Factors==

The platform affected can be:

The platform affected can be:

−

* Language: SQL

* Language: SQL

−

+

* Platform: Any (requires interaction with a SQL database)

−

* Platform: Any (requires interaction with an SQL database)

+

[[Glossary#SQL Injection|SQL Injection]] has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind.

[[Glossary#SQL Injection|SQL Injection]] has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind.

Essentially, the attack is accomplished by placing a meta character into data input to then place SQL commands in the control plane, which did not exist there before. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.

Essentially, the attack is accomplished by placing a meta character into data input to then place SQL commands in the control plane, which did not exist there before. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.

Many database servers, including Microsoft® SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

+

Many database servers, including Microsoft® SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error in Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, in databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

−

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [19]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:

+

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed. In this case the comment character serves to remove the trailing single-quote left over from the modified query. In a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:

<pre>

<pre>

Line 203:

Line 192:

Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.

Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.

−

+

==Related [[Threat Agents]]==

−

+

* [[:Category:Command Execution]]

−

==Related Threats==

+

−

+

−

*[[:Category:Command Execution]]

+

* [[Injection problem]]

* [[Injection problem]]

+

==Related [[Attacks]]==

+

* [[Top 10 2007-Injection Flaws | injection attack]]

+

* [[Blind SQL Injection]]

+

* [[Code Injection]]

+

* [[Double Encoding]]

+

* [[Interpreter_Injection#ORM_Injection]]

−

==Related Attacks==

+

==Related [[Vulnerabilities]]==

−

*[[Top 10 2007-Injection Flaws | injection attack]]

+

* [[:Category:Input Validation Vulnerability]]

−

+

−

*[[Blind SQL Injection]]

+

−

+

−

*[[Code Injection]]

+

−

+

−

*[[Double Encoding]]

+

−

+

−

== External References ==

+

−

+

−

*[http://www.greensql.net/ GreenSQL Open Source SQL Injection Filter]

+

−

+

−

==Related Vulnerabilities==

+

−

+

−

*[[:Category:Input Validation Vulnerability]]

+

−

+

−

+

−

==Related Countermeasures==

+

+

==Related [[Controls]]==

+

* [[Input Validation]]

+

* [[Output Validation]]

+

* [[Static Code Analysis]]

+

[[Category:FIXME|this was the text that was here before we added the links. Can it be deleted?

Avoidance and mitigation

Avoidance and mitigation

Line 237:

Line 217:

* Implementation: Use vigorous white-list style checking on any user input that may be used in an SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that has been entered in the database may neglect to escape meta-characters before use.

* Implementation: Use vigorous white-list style checking on any user input that may be used in an SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that has been entered in the database may neglect to escape meta-characters before use.

Revision as of 01:09, 27 April 2013

Overview

A SQL injection attack consists of insertion or "injection" of a 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 as 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.
SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

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

Authentication: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.

Authorization: If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL Injection vulnerability.

Integrity: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL Injection attack.

Risk Factors

The platform affected can be:

Language: SQL

Platform: Any (requires interaction with a SQL database)

SQL Injection has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind.

Essentially, the attack is accomplished by placing a meta character into data input to then place SQL commands in the control plane, which did not exist there before. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.

Example 2

The following C# code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:

The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:

SELECT * FROM items;

This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner.

Example 3

This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name hacker enters the string "hacker'); DELETE FROM items; --" for itemName, then the query becomes the following two queries:

Many database servers, including Microsoft® SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error in Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, in databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed. In this case the comment character serves to remove the trailing single-quote left over from the modified query. In a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:

One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from a whitelist of safe values or identify and escape a blacklist of potentially malicious values. Whitelisting can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, blacklisting is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers can:

Target fields that are not quoted

Find ways to bypass the need for certain escaped meta-characters

Use stored procedures to hide the injected meta-characters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. For example, the following PL/SQL procedure is vulnerable to the same SQL injection attack shown in the first example.

Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.