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 "OWASP Periodic Table of Vulnerabilities - SQL Injection"

From OWASP
Jump to: navigation, search
(Custom Code Solution)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
[[OWASP_Periodic_Table_of_Vulnerabilities#Periodic_Table_of_Vulnerabilities|Return to Periodic Table Working View]]
  
 
== SQL Injection ==
 
== SQL Injection ==
  
 
=== Root Cause Summary ===
 
=== Root Cause Summary ===
Applications that have insufficient input validations or non-validated literal strings concatenated into a dynamic SQL Statement and subsequently interpreted as code by the SQL Engine
+
Applications that have insufficient output encoding or non-validated literal strings concatenated into a dynamic SQL statement and subsequently interpreted as code by the SQL engine.
  
 
=== Browser / Standards Solution ===
 
=== Browser / Standards Solution ===
Line 10: Line 11:
  
 
=== Perimeter Solution ===
 
=== Perimeter Solution ===
Web Application Firewalls (WAFs) can help in reducing SQL Injection attacks by filtering popular and well known attack inputs. WAFs are driven by a set of predefined rules that can help mitigate SQL Inection attacks to a certain extent.
 
  
 
+
None
Complexity: High<br>
 
Impact: High
 
  
 
=== Generic Framework Solution ===
 
=== Generic Framework Solution ===
* '''Parametric Queries''' - Use parametric queries to execute any SQL commands
+
* '''Parameterized Queries''' - Use parameterized queries to execute any SQL commands
* '''Input Validation''' - Validate all inputs that are passed to the SQL statement for accuracy of datatypes, boundary limits and accepted characterset
+
* '''Input Validation''' - Validate all inputs that are passed to the SQL statement for accuracy of datatypes, boundary limits and accepted character set
* '''Escape Sequences''' - In cases where it is not possible to use parametric queries (like legacy code), ensure that the SQL engine sensitive characters are escaped appropriately. [ [[To provide a seperate link for this]] ]
+
* '''Escape Sequences''' - In cases where it is not possible to use parametric queries (like legacy code), ensure that the SQL engine sensitive characters are escaped appropriately. [ [[To provide a separate link for this]] ]
 
 
Complexity: Low<br>
 
Impact: High
 
  
 
=== Custom Framework Solution ===
 
=== Custom Framework Solution ===
  
Provide a common configuration functionality available to any feature/function. Configuration settings should allow multiple per-user rate limits as well as global rate limits to prevent denial of service.
+
None
  
Complexity: Low<br>
+
=== Custom Code Solution ===
Impact: High
 
  
=== Custom Code Solution ===
+
* When building custom solutions, make sure that SQL queries are constructed dynamically with table names and views after thorough and proper validation of the schema and the table/view.
* When building custom solutions, make sure that SQL queries are not constructed dynamically with the table names and views. If that is unavoidable, validate the schema and the table/view names before constructing the SQL query.
+
* As a precautionary measure, ensure that all tables have appropriate access control through policies.
* As a precuationay measure, ensure that the tables have appropriate access control through policies
 
 
* Whenever possible, when building custom solutions, use the underlying databases prepared queries library.
 
* Whenever possible, when building custom solutions, use the underlying databases prepared queries library.
 
+
* Stored procedures must not contain string-concatenated SQL queries, either.
Complexity: High<br>
 
Impact: High
 
  
 
=== Discussion / Controversy ===
 
=== Discussion / Controversy ===
  
Generic framework solution requires too much overhead to track request limits. Request rate limiting should be done in perimeter, not framework. Should combine with Denial of Service (Application-Based)? Custom Code solution is the same as Custom Framework Solution; Custom Code solution should be pushed into framework.
+
Web Application Firewalls (WAFs) can help in reducing SQL Injection attacks by filtering popular and well known attack inputs. WAFs are driven by a set of predefined rules that can help mitigate SQL Injection attacks to a certain extent. However, ultimately all injection flaws need to be solved as close to the point where the injection actually affects the target systems. In this case, that is as close to the construction of the SQL query as possible, in the application framework.
  
 
=== References ===
 
=== References ===
[http://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation Insufficient Anti-automation (WASC TC)]<br>
+
[[SQL Injection]]<BR>
[http://projects.webappsec.org/w/page/13246915/Brute%20Force Brute Force (WASC TC)]<br>
+
[http://projects.webappsec.org/w/page/13246963/SQL%20Injection SQL Injection (WASC)]<BR>
[[Testing for Brute Force (OWASP-AT-004)| Testing for Brute Force (OWASP Testing Guide)]]<br>
+
[http://cwe.mitre.org/data/definitions/89.html SQL Injection (CWE)]<BR>

Latest revision as of 22:16, 20 July 2013

Return to Periodic Table Working View

SQL Injection

Root Cause Summary

Applications that have insufficient output encoding or non-validated literal strings concatenated into a dynamic SQL statement and subsequently interpreted as code by the SQL engine.

Browser / Standards Solution

None

Perimeter Solution

None

Generic Framework Solution

  • Parameterized Queries - Use parameterized queries to execute any SQL commands
  • Input Validation - Validate all inputs that are passed to the SQL statement for accuracy of datatypes, boundary limits and accepted character set
  • Escape Sequences - In cases where it is not possible to use parametric queries (like legacy code), ensure that the SQL engine sensitive characters are escaped appropriately. [ To provide a separate link for this ]

Custom Framework Solution

None

Custom Code Solution

  • When building custom solutions, make sure that SQL queries are constructed dynamically with table names and views after thorough and proper validation of the schema and the table/view.
  • As a precautionary measure, ensure that all tables have appropriate access control through policies.
  • Whenever possible, when building custom solutions, use the underlying databases prepared queries library.
  • Stored procedures must not contain string-concatenated SQL queries, either.

Discussion / Controversy

Web Application Firewalls (WAFs) can help in reducing SQL Injection attacks by filtering popular and well known attack inputs. WAFs are driven by a set of predefined rules that can help mitigate SQL Injection attacks to a certain extent. However, ultimately all injection flaws need to be solved as close to the point where the injection actually affects the target systems. In this case, that is as close to the construction of the SQL query as possible, in the application framework.

References

SQL Injection
SQL Injection (WASC)
SQL Injection (CWE)