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

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

This is a draft of a section of the new Testing Guide v3

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.

Description of the Issue

SQL Wildcard attacks might affect all database back-ends but mainly affects SQL Server because of MS SQL Server LIKE operator supports some extra wildcards such as "[]","[^]","_" and "%".

In a typical web application if you were to enter "foo" into the search box, the resulting SQL query might be:

SELECT * FROM Article WHERE Content LIKE '%foo%'

In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.

SELECT TOP 10 * FROM Article WHERE Content LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'

So, if an attacker wanted to tie up the CPU for 6 seconds they would enter the following to the search box:

_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_

Black Box testing and example

Testing for SQL Wildcard Attacks:
Craft a query which will not return a result and includes several wildcards. You can use one of the example inputs below.
Send this data through the search feature of the application. If the application takes more time than a usual search, it is vulnerable.

Example Attack Inputs to send

• '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'
• '%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R"_)][%55](%66[x])%ba][$*"£$-9]_%54' bypasses modsecurity
• _[r/a)_ _(r/b)_ _(r-d)_
• %n[^n]y[^j]l[^k]d[^l]h[^z]t[^k]b[^q]t[^q][^n]!%
  
• %_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%
  

...
Result Expected:
IF the application is vulnerable, response time should be longer than the usual.

How to craft search keywords for testing

• Queries should return a few results as possible or even none at all. In this way we can be sure that we actually forced database server to search all records;
• During the OR combinations every OR statement should be different, otherwise the database will optimise it. Changing one character is enough;
• In Microsoft SQL Server, every character after an open bracket [ causes unusually longer execution time, this can be used to improve the affect, some examples:
  • LIKE '%_[a[! -z]@$!_% - 1050 ms.
  • LIKE '%_[aaaaaaaaa[! -z]@$!_%' - 1600 ms.
  • LIKE '%_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%' - 3700 ms.
• Longer queries will generally result with longer execution time. Craft the longest possible query allowed by the application;
• Starting with % and ending with % generally will cause more expensive queries;
• Some implementations might 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.

Gray Box testing and example

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.

References

Whitepapers

• DoS Attacks Using SQL Wildcards

Tools
Testing can be done manually. Also a fuzzer can employed to automate the process.