This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "SQL Injection"

From OWASP
Jump to: navigation, search
m (Avoidance and mitigation)
m (Avoidance and mitigation)
Line 45: Line 45:
 
* 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.
  
* [[Image:Advanced Topics on SQL Injection Protection.ppt|Advanced Topics on SQL Injection Protection]]
+
* [[Image:Advanced Topics on SQL Injection Protection.ppt]]
  
 
==Discussion ==
 
==Discussion ==

Revision as of 01:34, 31 May 2006


Overview

SQL Injection attacks are another instantiation of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

Consequences

  • Confidentiality: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL Injection vulnerabilities.
  • 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 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 SQL Injection attack.

Exposure period

  • Requirements specification: A non-SQL style database which is not subject to this flaw may be chosen.
  • Implementation: If SQL is used, all flaws resulting in SQL Injection problems must be mitigated at the implementation level.

Platform

  • Language: SQL
  • Platform: Any (requires interaction with an SQL database)

Required resources

Any

Severity

Medium to High

Likelihood of exploit

Very High

Avoidance and mitigation

  • Requirements specification: A non-SQL style database which is not subject to this flaw may be chosen.
  • 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.

Discussion

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.

Examples

In SQL:

select id, firstname, lastname from authors

If one provided:

Firstname: evil'ex
Lastname: Newman

the query string becomes:

select id, firstname, lastname from authors where forename = 'evil'ex' and surname ='newman'
which the database attempts to run as 
Incorrect syntax near al' as the database tried to execute evil. 

A safe version of the above SQL statement could be coded in Java as:

String firstname = req.getParameter("firstname");
String lastname = req.getParameter("lastname");
// FIXME: do your own validation to detect attacks
String query = "SELECT id, firstname, lastname FROM authors WHERE forename = ? and surname = ?";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, firstname );
pstmt.setString( 2, lastname );
try
{
	ResultSet results = pstmt.execute( );
}

Related problems