Testing for SQL Wildcard Attacks (OWASP-DS-001) - Revision history

KirstenS: Testing for SQL Wildcard Attacks moved to Testing for SQL Wildcard Attacks (OWASP-DS-001)

2008-12-15T22:54:56Z

Testing for SQL Wildcard Attacks moved to Testing for SQL Wildcard Attacks (OWASP-DS-001)

KirstenS: /* References */

2008-12-14T02:22:46Z

‎References

KirstenS: /* How to craft search strings for testing */

2008-12-14T02:21:56Z

‎How to craft search strings for testing

Mmeucci: /* References */

2008-11-02T13:59:58Z

‎References

Mmeucci at 13:59, 2 November 2008

2008-11-02T13:59:04Z

Namn at 03:57, 4 September 2008

2008-09-04T03:57:54Z

KirstenS: /* Brief Summary */

2008-08-30T22:08:16Z

‎Brief Summary

KirstenS: /* Brief Summary */

2008-08-30T22:07:54Z

‎Brief Summary

Marco: /* Gray Box testing and example */

2008-08-22T06:40:17Z

‎Gray Box testing and example

Marco: /* How to craft search strings for testing */

2008-08-22T06:39:28Z

‎How to craft search strings for testing

@@ Line 61: / Line 61: @@
 * [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]
 '''Tools'''<br>
-* Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.
+* Testing can be done manually. Also, a [[Fuzzing|fuzzer]] can employed to automate the process.

@@ Line 40: / Line 40: @@
 * Queries should return as few results as possible or even none at all.  In this way, we can be sure that we actually forced the database server to search all records.
-* During the OR combinations every OR statement should be different, otherwise the database will optimize it.  Changing one character is enough.
+* During the OR combinations, every OR statement should be different, otherwise the database will optimize it.  Changing one character is enough.
 * In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually long execution time. This can be used to improve the effect, for example:
 ** <nowiki>LIKE '%_[a[! -z]@$!_%               - 1050 ms. </nowiki>

@@ Line 61: / Line 61: @@
 * [http://www.portcullis.co.uk/uplds/wildcard_attacks.pdf DoS Attacks Using SQL Wildcards]
 '''Tools'''<br>
-Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.
+* Testing can be done manually. Also a [[Fuzzing|fuzzer]] can employed to automate the process.

← Older revision		Revision as of 13:59, 2 November 2008
Line 1:		Line 1:
	{{Template:OWASP Testing Guide v3}}		{{Template:OWASP Testing Guide v3}}
−
−	~~'''This is a draft of a section of the new Testing Guide v3'''~~

	== Brief Summary ==		== Brief Summary ==

@@ Line 18: / Line 18: @@
   <nowiki>SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'</nowiki>
-So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:
+So, if the tester wanted to tie up the CPU for 6 seconds they would enter the following to the search box:
   <nowiki>_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_</nowiki>

← Older revision	Revision as of 22:54, 15 December 2008
(No difference)

@@ Line 4: / Line 4: @@
 == Brief Summary ==
-SQL Wildcard Attacks are about forcing the underlying database to carry out CPU-intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of the web applications. Successful exploitation of this attack will cause Denial of Service.
+SQL Wildcard Attacks are about forcing the underlying database to carry out CPU-intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of web applications. Successful exploitation of this attack will cause Denial of Service.
 <br>

@@ Line 55: / Line 55: @@
 '''Testing for SQL Wildcard Attacks:'''
-Query execution times can be observed in the database server, if certain queries takes longer time it can be an indication of SQL wildcard attacks.
+Query execution times can be observed in the database server, if certain queries take longer time it can be an indication of SQL wildcard attacks.
-To test against application layer DoS attacks, it's important to watch HTTP logs and analyze response times. If response times of certain pages in certain queries is longer than usual, those pages might be susceptible to SQL wildcard attacks.
+To test against application layer DoS attacks, it's important to watch HTTP logs and analyze response times. If the response times of certain pages in certain queries is longer than usual, those pages might be susceptible to SQL wildcard attacks.
 == References ==

@@ Line 41: / Line 41: @@
 === How to craft search strings for testing ===
-* Queries should return as few results as possible or even none at all.  In this way we can be sure that we actually forced the database server to search all records;
+* Queries should return as few results as possible or even none at all.  In this way, we can be sure that we actually forced the database server to search all records.
-* During the OR combinations every OR statement should be different, otherwise the database will optimize it.  Changing one character is enough;
+* During the OR combinations every OR statement should be different, otherwise the database will optimize it.  Changing one character is enough.
-* In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually long execution time, this can be used to improve the effect, some examples:
+* In Microsoft SQL Server, every character after an open bracket '''[''' causes unusually long execution time. This can be used to improve the effect, for example:
 ** <nowiki>LIKE '%_[a[! -z]@$!_%               - 1050 ms. </nowiki>
 ** <nowiki>LIKE '%_[aaaaaaaaa[! -z]@$!_%'             - 1600 ms. </nowiki>
 ** <nowiki>LIKE '%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%'  - 3700 ms.</nowiki>
-* Longer queries will generally result with longer execution time. Craft the longest possible query allowed by the application;
+* Longer queries will generally result in longer execution time. Craft the longest possible query allowed by the application.
-* Starting with % and ending with % will generally cause longer running queries;
+* Starting with % and ending with % will generally cause longer running queries.
-* Some search implementations may cache search results. During the testing every search query should be slightly different to avoid this;
+* Some search implementations may cache search results. During the testing, every search query should be slightly different to avoid this.
 * Performance is always about experimenting.  Try different combinations to find the most expensive queries for that particular target system and data.