Difference between revisions of "OWASP Periodic Table of Vulnerabilities - SQL Injection"

From OWASP
Jump to: navigation, search
(Generic Framework Solution)
 
(10 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 and allow an external user to manipulate the SQL commands and retrieve results that would result in a compromise of the data.
+
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 separate link for this]] ]
Provide configurable per-user/session request rate limits. For authenticated transactions, limits should be configurable on a per-user or per-session basis. Configuration should allow combining multiple limits of the form "# of requests per time period". For example, an administrator should be combine "10 requests per minute" with "500 requests per day" in order to simultaneously apply policies which prevent users from automatic crawling/screen scraping as well as longer-term slow leeching activities.
+
 
+
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>
+
Impact: High
+
  
 
=== Custom Code Solution ===
 
=== Custom Code Solution ===
Any feature sensitive to high transaction rates should expose configurable rate limits per user or globally per feature.
 
  
Complexity: Low<br>
+
* 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.
Impact: High
+
* 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 ===
 
=== 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 17:16, 20 July 2013

Return to Periodic Table Working View

Contents

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)