Application Security - Implementing Database Security and Auditing - page 151

User ID: ` OR ``=`
Password: ` OR ``=`
In this case the sqlString that would be used to create the result set would
be as follows:
select USERID from USER where USERID = `` OR ``=`` and PWD = ``
OR ``=``
which would certainly set the userHasBeenAuthenticated variable to
true, even though I have no clue of what a legitimate user ID and pass-
word may be.
Let's look at some additional methods employed as part of a SQL injec-
tion attack. These methods are merely permutations on the theme shown
previously and are all based on the use of string concatenation and nonvali-
dated user data. Still, it is useful to understand how easy and how flexible
SQL injection can be before moving on to see what can be done to address
this problem.
I mentioned that SQL injection is not specific to any database type, and
this is true. There are, however, some specific attack methods that utilize
database-specific functions, usually based on the fact that each database has
a slightly different SQL dialect. One example of this is the use of comments
(e.g., the use of -- in SQL Server and the use of /* and */ in MySQL). The
use of -- in SQL Server is helpful because SQL injection usually involves a
lot of trial and error for getting the strings just right. In our user authentica-
tion example, it is possible that the application validates passwords to have a
length of only 12 characters, causing the injection shown above to fail. In
this case I can put in the following user ID and password:
User ID: ` OR ``=`` --
Password: abc
Because anything after the -- will be ignored, the injection will work
even without any specific injection into the password predicate.
Let's look at another type of injection to help explain the motivation for
using other commenting features in the database. In this case I will not try
to get at any information—I just want to bring the application down. In
this case I can do something like:
User ID: ` ; DROP TABLE USER ;--