Difference between revisions of "SQL injection/Countermeasures/Sanitizing"

Revision as of 05:50, 19 July 2012

SQL injection > Countermeasures > Sanitizing

Any time improper sanitizing takes place there is a potential for partial sanitizing, and may make the exploitation process highly difficult if not impossible.

Partial sanitizing

Partial sanitizing may affect any or more (unlisted here) of the following important syntax characters and result in them being encoded in some fashion, escaped, or removed entirely. In many circumstances, it is possible to craft injection queries without syntax characters, resulting in filter bypass and sometimes IDS evasion.

• The space character (or all whitespace)

Jump to sql injection without whitespace

• The single quote and double quote characters: ', "

Jump to sql injection without quotes

• The tag or "equals" comparative operators: <, >, and =

Jump to sql injection without tags

• The comma character: ,

Jump to sql injection without commas

• The parenthesis characters: ( and )

Deprecated sanitizing

PHP's addslashes() function (now deprecated) relied on the unhex() function. The goal of addslashes() was to add an escape (\) behind any single quotes (') entered into a string. When multi-byte character sets (or collations) are in use, this can cause a vulnerability to occur. If a valid multi-byte character ends in 0x5c (the escape), it is possible to circumvent the escape completely by placing the first byte of that character before the single quote. When unhex() is called against the now escaped single-quote, it sees the two bytes as a single character, allowing the quote (0x27) to escape the string unscathed. An example prefix for a non-utf8 character set's multi-byte prefix that accepts 0x5c as an ending is 0xbf, so one could use %bf%27 in a url to bypass the use of addslashes().