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
(Generic Framework Solution)
Line 17: Line 17:
  
 
=== Generic Framework Solution ===
 
=== Generic Framework Solution ===
*[[Parametric Queries]] - Use parametric queries for executing any SQL commands.
+
* '''Parametric Queries''' - Use parametric queries for executing any SQL commands.
  
 
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.
 
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.

Revision as of 06:48, 6 May 2013

SQL Injection

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.

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 Inection attacks to a certain extent.


Complexity: High
Impact: High

Generic Framework Solution

  • Parametric Queries - Use parametric queries for executing any SQL commands.

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
Impact: High

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.

Complexity: Low
Impact: High

Custom Code Solution

Any feature sensitive to high transaction rates should expose configurable rate limits per user or globally per feature.

Complexity: Low
Impact: High

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

Insufficient Anti-automation (WASC TC)
Brute Force (WASC TC)
Testing for Brute Force (OWASP Testing Guide)