Message-ID: <20050419210541.F25776D2@lists.grok.org.uk>
Date: Tue Apr 19 22:05:47 2005
From: psmelson at comcast.net (Paul Melson)
Subject: FW: Introducing a new generic approach
	todetecting SQL injection

At the end of the day, though, isn't this just security through obscurity?
If the attacker uses an injection string that creates an always-false
condition, then the injection succeeds, does it not?

PaulM

-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of
Glenn.Everhart@...se.com
Sent: Tuesday, April 19, 2005 2:33 PM
To: full-disclosure@...ts.grok.org.uk
Subject: [Full-disclosure] FW: Introducing a new generic approach
todetecting 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
**********************************************************************

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists