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 "Talk:Testing for SQL Wildcard Attacks (OWASP-DS-001)"

From OWASP
Jump to: navigation, search
 
(One intermediate revision by one other user not shown)
Line 7: Line 7:
 
----
 
----
  
This section could be expanded to talk about algorithmic complexity attacks, of which the SQL wildcard attack seems to be a subclass:
+
This seems to mix two vulnerabilities/attacks. One consists of bypassing indexes that are defined on a table. In the search box example, if the user searches for, say, "foo", the database can use indexes to quickly locate the matching records. If the user inputs "*", no index can be found and the entire table has to be scanned, which is expensive and unwanted. Possible fixes here: write better queries (for example, stop after finding N matches), filter input to remove metacharacters.
 +
The second attack class is algorithmic complexity attacks. There's a nice description (and it's the standard reference) at http://www.cs.rice.edu/~scrosby/hash/ Essentially, in many cases, input can be crafted so that the performance of several data structures and algorithms on them (most notably, hash functions and regular expressions) can be degraded to its worst case. Some references:
 
* http://www.cs.rice.edu/~scrosby/hash/ (hash functions)
 
* http://www.cs.rice.edu/~scrosby/hash/ (hash functions)
 +
* http://www.cs.rice.edu/~scrosby/hash/slides/USENIX-RegexpWIP.2.ppt (regular expression)
 
* http://www.usenix.org/event/woot08/tech/full_papers/drewry/drewry_html/ (regular expression)
 
* http://www.usenix.org/event/woot08/tech/full_papers/drewry/drewry_html/ (regular expression)
  
 
[[User:Marco|Marco]] 02:34, 22 August 2008 (EDT)
 
[[User:Marco|Marco]] 02:34, 22 August 2008 (EDT)

Latest revision as of 22:54, 15 December 2008

v3 Reviewer Notes

I don't think we should list "%" as an "extra" wildcard as it is the standard SQL (Oracle, MS, My, etc) wildcard. Rick.mitchell 10:17, 13 August 2008 (EDT)


This seems to mix two vulnerabilities/attacks. One consists of bypassing indexes that are defined on a table. In the search box example, if the user searches for, say, "foo", the database can use indexes to quickly locate the matching records. If the user inputs "*", no index can be found and the entire table has to be scanned, which is expensive and unwanted. Possible fixes here: write better queries (for example, stop after finding N matches), filter input to remove metacharacters. The second attack class is algorithmic complexity attacks. There's a nice description (and it's the standard reference) at http://www.cs.rice.edu/~scrosby/hash/ Essentially, in many cases, input can be crafted so that the performance of several data structures and algorithms on them (most notably, hash functions and regular expressions) can be degraded to its worst case. Some references:

Marco 02:34, 22 August 2008 (EDT)