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

From OWASP
Jump to: navigation, search
(Root Cause Summary)
m (Minor grammar/spelling edits)
(7 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 input validation 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.
+
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.
 
+
 
+
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>
+
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.
+
* 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 the tables have appropriate access control through policies
Complexity: Low<br>
+
* Whenever possible, when building custom solutions, use the underlying databases prepared queries library.
Impact: High
+
* 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.
 
  
 
=== References ===
 
=== References ===
[http://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation Insufficient Anti-automation (WASC TC)]<br>
 
[http://projects.webappsec.org/w/page/13246915/Brute%20Force Brute Force (WASC TC)]<br>
 
[[Testing for Brute Force (OWASP-AT-004)| Testing for Brute Force (OWASP Testing Guide)]]<br>
 

Revision as of 15:52, 15 May 2013

Return to Periodic Table Working View

Contents

SQL Injection

Root Cause Summary

Applications that have insufficient input validation 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

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.

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

References