Application Security - Implementing Database Security and Auditing - page 152

Password: abc
or
User ID: ` ; DELETE FROM USER WHERE ``=`
Password: ` OR ``=`
These would translate to the following two SQL Server statements:
select USERID from USER where USERID = ``; DROP TABLE USER ;--`
and PWD = `` OR ``=``
select USERID from USER where USERID = ``; DELETE FROM USER
WHERE ``=`` and PWD = `` OR ``=``
The second case is especially interesting for two reasons: (1) it does not
depend on the use of --, and (2) it uses a DELETE call, which is probably
used by the application. The example using the DROP command can
probably be avoided by revoking privileges to drop tables from the appli-
cation login, and this is probably not something you'd like a production
application to be doing anyway. Deleting from the USER table, on the
other hand, is probably perfectly fine and may be a supported function in
the application.
One of the techniques you will see later on in combating SQL injection
involves looking for certain patterns—sometimes called signatures . These
look for patterns that are commonly used by hackers and that are not com-
monly found in “normal” SQL generated by the application. In bypassing
these signature functions, hackers can use comments. In MySQL, for exam-
ple, if I suspect that some security layer may be looking for DROPs or
DELETEs, I can hide my injection using strings of the following structure:
DR/**/OP TAB/**/LE USER
DE/**/LE/**/TE FR/**/OM USER
Another popular SQL injection technique involves the use of UNION
ALL SELECT to grab data from any table in the system. The syntax for this
SELECT option is:
SELECT ...
UNION [ALL | DISTINCT]
SELECT ...