Application Security - Implementing Database Security and Auditing - page 163

this access set will not affect operations of the application in any way but
will limit the liability that is associated with application vulnerabilities such
as SQL injection.
Having covered some implementation options you can employ to elimi-
nate SQL injection vulnerabilities, let's move on to monitoring SQL access
and alerting when a potential SQL injection attack may be occurring.
First, let's review why you should even bother to monitor for SQL injec-
tion. You may be thinking that there is no point in monitoring or looking
for SQL injection, because by the time you can react it is way too late and
the hacker has already taken all the data away. The reason for monitoring
SQL injection is twofold. First, attacks take time. Unless your application
environment is really broken and very poorly coded, a hacker will have to
go through fairly lengthy trial-and-error processes to be able to use the right
SQL injection method to get at the data. If you have a good monitoring
solution that is set up to do real-time or near real-time notification and if
you have a good incident response infrastructure, then you may be able to
stop an attack while it is taking place and you may even be able to catch the
hacker (e.g., by identifying which IP or MAC address the attack is coming
from). The second reason is that if you identify a SQL injection attack, you
can get rid of the vulnerability in the application and improve your overall
security health over time.
So now that you're (hopefully) convinced that you should monitor for
SQL injection, the question is what you should be looking for. The answer
to this falls into three separate categories: attack signature, exceptions, and
divergence from a baseline.
Tracking attack signatures is the simplest and is supported in many
intrusion detection systems (IDSs) and IDS-like systems that claim support
for database intrusion detection. The idea here is to identify certain patterns
(called signatures of the attack) and look for them. The signatures will
match up with the commonly used techniques of SQL injection. For exam-
ple, you can look for signatures such as 1=1 or UNION SELECT or
WHERE clauses that appear after a -- comment. You can do this either
with an IDS that supports SQL signatures or by getting a dump of the SQL
used to hit the database (through a database monitoring solution) and look
for the signatures within these strings. The problems with this approach
(and the reasons that it has not been very successful, both within the data-
base world and more generally in the security world) are that there are too
many ways to carry out such an attack, and the signatures may actually
match up with something that is legal. To illustrate the first problem, think
how many different predicates you can think up that compute to an always