SQL Injection Attacks and Defense - 2009

Code-Level Defenses • Chapter 8 357
In instances where user input includes one of the characters in Table 8.2, you can ensure
that they are treated correctly by defining an escape character for the query, preceding the
wildcard character with the escape character, and specifying the escape character in the
query using an ESCAPE clause. Here is an example:
SELECT * from users WHERE name LIKE 'a%'
-- Vulnerable. Returns all users starting with 'a'
SELECT * from users WHERE name LIKE 'a\%' ESCAPE '\'
-- Not vulnerable. Returns user 'a%', if one exists
Note that when using the ESCAPE clause, you can specify any single character to
be used as the escape character. I used the backslash in the preceding example because this
is a common convention when escaping content.
Additionally, on Oracle 10g Release 1 and later, there is one more method of quoting
a string—the “q” quote, which takes the form q’[QUOTE CHAR]string[QUOTE CHAR]’.
The quote character can be any single character that doesn’t occur in the string, with the
exception that Oracle expects matching brackets (i.e., if you’re using “[” as the opening
quote character, it expects the matching “]” as the closing quote character). The following
are some examples of quoting strings in this way:
q'(5%)'
q'AO'BoyleA'
Oracle dbms_assert
With Oracle 10g Release 2, Oracle introduced a new package called dbms_assert. This package
was then back-ported to older database versions (until Oracle 8i). You should use dbms_
assert to perform input validation if parameterized queries (e.g., in FROM clauses) are not
possible. dbms_assert offers seven different functions (ENQUOTE_LITERAL, ENQUOTE_
NAME, NOOP, QUALIFIED_SQL_NAME, SCHEMA_NAME, SIMPLE_SQL_NAME,
and SQL_OBJECT_NAME) to validate different types of input.
Wa r n i n g
You should not use the NOOP function, because the function does nothing
and does not protect you from SQL injection. Oracle uses this function
internally to avoid false positives during automatic source code scanning.