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 "Top 10 2007-Injection Flaws"

From OWASP
Jump to: navigation, search
Line 2: Line 2:
  
  
{{FIXUP|Neil Smithline|Insert Text Here}}
+
{{FIXUP|Neil Smithline|Replace With Final Text Here}}
 +
 
 +
Injection flaws, particularly SQL injection, are common in web applications. There are many types of injections: SQL, LDAP, XPath, XSLT, HTML, XML, OS command injection and many more.
 +
 
 +
Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. Attackers trick the interpreter into executing unintended commands via supplying specially crafted data. Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application. In the worst case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments.
 +
 
 +
== Environments Affected ==
 +
 
 +
All web application frameworks that use interpreters or invoke other processes are vulnerable to injection attacks.  This includes any components of the framework, which might use back-end interpreters.
 +
 
 +
== Vulnerability ==
 +
 
 +
If user input is passed into an interpreter without validation or encoding, the application is vulnerable. Check if user input is supplied to dynamic queries, such as:
 +
 
 +
$sql = "SELECT * FROM table WHERE id = '" . $_REQUEST['id’] . "’";
 +
 
 +
// Line of parameterized SQL in Java
 +
 
 +
== Verifying Security ==
 +
 
 +
The goal is to verify that user data cannot modify the meaning of commands and queries sent to any of the interpreters invoked by the application.
 +
 
 +
Automated approaches: Many vulnerability scanning tools search for injection problems, particularly SQL injection. Static analysis tools that search for uses of unsafe interpreter APIs are useful, but frequently cannot verify that appropriate validation or encoding might be in place to protect against the vulnerability. If the application catches 501 / 500 internal server errors, or detailed database errors, it can significantly hamper automated tools, but the code may still be at risk. Automated tools may be able to detect LDAP / XML injections / XPath injections.
 +
 
 +
Manual approaches: The most efficient and accurate approach is to check the code that invokes interpreters. The reviewer should verify the use of a safe API or that appropriate validation and/or encoding has occurred. Testing can be extremely time-consuming and spotty because the attack surface of most applications is so large.
 +
 
 +
== Protection ==
 +
 
 +
Avoid the use of interpreters when possible. If you must invoke an interpreter, the key method to avoid injections is the use of safe APIs, such as strongly typed parameterized queries and object relational mapping (ORM) libraries. These interfaces handle all data escaping, or do not require escaping.  Note that while safe interfaces solve the problem, validation is still recommended in order to detect attacks.
 +
 
 +
Using interpreters is dangerous, so it's worth it to take extra care, such as the following:
 +
 
 +
'''*Input validation.''' Use a standard input validation mechanism to validate all input data for length, type, syntax, and business rules before accepting the data to be displayed or stored. Use an "accept known good" validation strategy. Reject invalid input rather than attempting to sanitize potentially hostile data.  Do not forget that error messages might also include invalid data.
 +
'''*Use strongly typed parameterized query APIs''' with placeholder substitution markers, even when calling stored procedures
 +
'''*Enforce least privilege''' when connecting to databases and other backend systems
 +
'''*Avoid detailed error messages''' that are useful to an attacker
 +
'''*Be careful when using stored procedures''' as they can be injectable (such as via the use of exec() or concatenating arguments within the stored procedure)
 +
'''*Do not use dynamic query interfaces''' (such as mysql_query() or similar)
 +
'''*Do not use simple escaping functions''', such as PHP’s addslashes() or character replacement functions like str_replace("’", "’’"). These are weak and have been successfully exploited by attackers.
 +
'''*Watch out for canonicalization errors.'''  Inputs must be decoded and canonicalized to the application’s current internal representation before being validated.  Make sure that your application does not decode the same input twice.  Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked.
 +
Language specific recommendations:
 +
 
 +
*Java EE – use strongly typed PreparedStatement, or ORMs such as Hibernate or Spring
 +
*.NET – use strongly typed parameterized queries, such as SqlCommand with SqlParameter or an ORM like Hibernate.
 +
*PHP – use PDO with strongly typed parameterized queries (using bindParam())
 +
 
 +
== Samples  ==
 +
 
 +
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5121 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5121]   
 +
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4953 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4953] 
 +
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4592 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4592]
 +
 
 +
== References ==
 +
 
 +
*CWE: CWE-89 (SQL Injection), CWE-77 (Command Injection), CWE-90 (LDAP Injection), CWE-91 (XML Injection), CWE-93 (CRLF Injection), others.
 +
*WASC Threat Classification:
 +
[http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml]
 +
[http://www.webappsec.org/projects/threat/classes/sql_injection.shtml http://www.webappsec.org/projects/threat/classes/sql_injection.shtml]
 +
http://www.webappsec.org/projects/threat/classes/os_commanding.shtml
 +
*OWASP, [http://www.owasp.org/index.php/SQL_Injection http://www.owasp.org/index.php/SQL_Injection]
 +
*OWASP, [http://www.owasp.org/index.php/Guide_to_SQL_Injection http://www.owasp.org/index.php/Guide_to_SQL_Injection]
 +
*OWASP, [http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection]
 +
*OWASP, [http://www.owasp.org/index.php/Testing_for_SQL_Injection http://www.owasp.org/index.php/Testing_for_SQL_Injection]
 +
*SQL Injection, [http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf]
 +
*Advanced SQL Injection, [http://www.ngssoftware.com/papers/advanced_sql_injection.pdf http://www.ngssoftware.com/papers/advanced_sql_injection.pdf ]   
 +
*More Advanced SQL Injection, [http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf ] 
 +
*Hibernate, an advanced object relational manager (ORM) for J2EE and .NET, [http://www.hibernate.org/ http://www.hibernate.org/]
 +
*J2EE Prepared Statements, [http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html]
 +
*How to: Protect from SQL injection in ASP.Net, [http://msdn2.microsoft.com/en-us/library/ms998271.aspx http://msdn2.microsoft.com/en-us/library/ms998271.aspx]
 +
*PHP PDO functions, [http://php.net/pdo http://php.net/pdo]
 +
 
  
  
  
 
{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Malicious File Execution|useprev=PrevLink|prev=-Cross Site Scripting|usemain=MainLink|main=}}
 
{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Malicious File Execution|useprev=PrevLink|prev=-Cross Site Scripting|usemain=MainLink|main=}}

Revision as of 23:57, 13 May 2007

«««« Main
()
»»»»


FIXUP: {{{1}}}: {{{2}}}


Injection flaws, particularly SQL injection, are common in web applications. There are many types of injections: SQL, LDAP, XPath, XSLT, HTML, XML, OS command injection and many more.

Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. Attackers trick the interpreter into executing unintended commands via supplying specially crafted data. Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application. In the worst case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments.

Environments Affected

All web application frameworks that use interpreters or invoke other processes are vulnerable to injection attacks. This includes any components of the framework, which might use back-end interpreters.

Vulnerability

If user input is passed into an interpreter without validation or encoding, the application is vulnerable. Check if user input is supplied to dynamic queries, such as:

$sql = "SELECT * FROM table WHERE id = '" . $_REQUEST['id’] . "’";

// Line of parameterized SQL in Java

Verifying Security

The goal is to verify that user data cannot modify the meaning of commands and queries sent to any of the interpreters invoked by the application.

Automated approaches: Many vulnerability scanning tools search for injection problems, particularly SQL injection. Static analysis tools that search for uses of unsafe interpreter APIs are useful, but frequently cannot verify that appropriate validation or encoding might be in place to protect against the vulnerability. If the application catches 501 / 500 internal server errors, or detailed database errors, it can significantly hamper automated tools, but the code may still be at risk. Automated tools may be able to detect LDAP / XML injections / XPath injections.

Manual approaches: The most efficient and accurate approach is to check the code that invokes interpreters. The reviewer should verify the use of a safe API or that appropriate validation and/or encoding has occurred. Testing can be extremely time-consuming and spotty because the attack surface of most applications is so large.

Protection

Avoid the use of interpreters when possible. If you must invoke an interpreter, the key method to avoid injections is the use of safe APIs, such as strongly typed parameterized queries and object relational mapping (ORM) libraries. These interfaces handle all data escaping, or do not require escaping. Note that while safe interfaces solve the problem, validation is still recommended in order to detect attacks.

Using interpreters is dangerous, so it's worth it to take extra care, such as the following:

*Input validation. Use a standard input validation mechanism to validate all input data for length, type, syntax, and business rules before accepting the data to be displayed or stored. Use an "accept known good" validation strategy. Reject invalid input rather than attempting to sanitize potentially hostile data. Do not forget that error messages might also include invalid data. *Use strongly typed parameterized query APIs with placeholder substitution markers, even when calling stored procedures *Enforce least privilege when connecting to databases and other backend systems *Avoid detailed error messages that are useful to an attacker *Be careful when using stored procedures as they can be injectable (such as via the use of exec() or concatenating arguments within the stored procedure) *Do not use dynamic query interfaces (such as mysql_query() or similar) *Do not use simple escaping functions, such as PHP’s addslashes() or character replacement functions like str_replace("’", "’’"). These are weak and have been successfully exploited by attackers. *Watch out for canonicalization errors. Inputs must be decoded and canonicalized to the application’s current internal representation before being validated. Make sure that your application does not decode the same input twice. Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked. Language specific recommendations:

  • Java EE – use strongly typed PreparedStatement, or ORMs such as Hibernate or Spring
  • .NET – use strongly typed parameterized queries, such as SqlCommand with SqlParameter or an ORM like Hibernate.
  • PHP – use PDO with strongly typed parameterized queries (using bindParam())

Samples

References

  • CWE: CWE-89 (SQL Injection), CWE-77 (Command Injection), CWE-90 (LDAP Injection), CWE-91 (XML Injection), CWE-93 (CRLF Injection), others.
  • WASC Threat Classification:

http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml http://www.webappsec.org/projects/threat/classes/sql_injection.shtml http://www.webappsec.org/projects/threat/classes/os_commanding.shtml



«««« Main
()
»»»»

© 2002-2007 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 2.5 license. Some rights reserved.