Date: Tue Apr 19 20:07:06 2005
From: Glenn.Everhart at chase.com (Glenn.Everhart@...se.com)
Subject: FW: Introducing a new generic approach to
	detecting SQL injection

Folks -

The following scheme looks like it could be helpful, apart from runtime cost
(which would tend to be limited since it is only where using human entered
data). Anyone see serious holes? Concur? Disagree? This seemed just crazy enough
to work when it occurred to me...

Thanks
Glenn Everhart


As you know, blocking SQL injection with filters on characters is painful and
not always successful. I got thinking about it and thought of an approach
that might detect such activity, and which is pretty generic.

The idea is that SQL in web apps gets used by shoving some SQL command code
into a DBMS, tacking one or more user inputs (possibly edited) onto a prefix
part that is part of the app. In examples, this is often a SELECT statement
but in principle others could be used. Then after the input there will be
other stuff to complete the statement.

Normally when valid input is present, this gives legal SQL that does something.
However when there is SQL injection, generally you see the user input piece
being some condition to cause the initial statement to be legal all the time followed
by whatever mischief is desired, followed by something to comment out whatever
else is there since it would otherwise make the whole not look legal.

If I want to detect SQL injection, one way to do it could be to put in the prefix and
the user piece, and follow it with some condition that will prevent the statement
from working when valid input is present...the idea is to wind up with something
like 

select password from users where user = '<user input>' and hell has frozen over and 1 = 0

(so the undisturbed statement will never be executed if valid input is present).
If you try to parse this with the user input and it comes out to be valid and ok to
execute, that would seem to indicate something strange is going on with <user input>
and that an attack is going on.

Now a problem is that you don't want to allow your database to be corrupted with
some such attack before you can react, seeing that allowing your business to be hosed
and THEN complaining seems inadequate.  Even if there is nothing that will allow
such statements to be run in a test mode, though, they could be run against a dummy
database whose corruption would not matter. 

At any rate this seems like a technique worth a look as a way to detect mischief which
is at any rate different from character filters and could make apps a bit safer.

Glenn C. Everhart
18 April 2005


A human being should be able to change a diaper, plan an invasion, butcher a 
hog, conn a ship, design a building, write a sonnet, balance accounts, build a 
wall, set a bone, comfort the dying, take orders, give orders, cooperate, act 
alone, solve equations, analyze a new problem, pitch manure, program a computer, 
cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -R.A.H.
 


**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************

Powered by blists - more mailing lists