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)"
m (New page: :: 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. ~~~~) |
m (Talk:Testing for SQL Wildcard Attacks moved to Talk:Testing for SQL Wildcard Attacks (OWASP-DS-001)) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | __TOC__ | |
| + | |||
| + | == 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. [[User:Rick.mitchell|Rick.mitchell]] 10:17, 13 August 2008 (EDT) | I don't think we should list "%" as an "extra" wildcard as it is the standard SQL (Oracle, MS, My, etc) wildcard. [[User:Rick.mitchell|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: | ||
| + | * 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) | ||
| + | |||
| + | [[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:
- 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)
Marco 02:34, 22 August 2008 (EDT)
