Gabriel,

Can you give me a rundown on how a sting like "dr/*foo*/op" would translate
as drop? Trying this in query analyzer does not seem  to work.

se/*foo*/lect * from users
 where archivebit = 1
order by firstname

Doesn't work...

So I created a table called foo and then ran this query like your example:

dr/*foo*/op table foo  - still no dice

I've never seen successful syntax like that used in t-sql.

The function code does indeed generate false positives and it is a stop gap
to be sure... But I'm not so sure getting around it is as easy as you seem
to indicate. 

Perhaps using inline comments is a method used against a different platform?
I'd be interested to find out.

Moreover, the point has been made "responsibly" over and over and over again
that these measures and NOT the fix - simply a way to stem the tide
temporarily while a defense (hopefully a defense in depth) is implemented.
Most of the folks on here who have been victimized by this malicious code
need a way to stop THIS attack while they finally get their code in order...
That's the purpose of these stop gap measures. Yes it's true the next attack
might step right over them - but these poor site owners need get a  breather
so they can make those other more important necessary changes. That's real
world in the trenches... No one is advocating this sanitizing function as a
panacea - mearly another arrow in the quiver.

My suggestion to you is that since you feel you have a better mouse trap,
rather than just pepper the list with pendantic criticism, post some of that
fancy regex code that you think would be a better stop gap :) That might
help some of the folks who actually need your advice.  If you post such a
function it would be much appreciated (I'd certainly like it).

-Mark

Mark A. Kruger, CFG, MCSE
(402) 408-3733 ext 105
www.cfwebtools.com
www.coldfusionmuse.com
www.necfug.com

-----Original Message-----
From: Gabriel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 23, 2008 9:49 PM
To: CF-Talk
Subject: RE: (ot) URL Hack Attempt Leaves Me Scractching My Head...

With this latest spate of SQL attacks it has at least alerted CF (and non CF
coders hopefully) to the importance of sql injection and input sanitisation.
However I am noticing that almost all of the drop-in 'patches', almost all
of them seem to be straight list/array searches and there is almost no use
of regular expressions, meaning that these 'solutions' can barely even be
considered as suitable stop gaps until more appropriate measures can be
taken (cfqueryparam, sql permissions, etcetera) as they really can only stop
the most basic attempts and are likely to produce an inordinate number of
false positives (someone earlier noted that an admin was blacklisted for
using declare in a perfectly acceptable context).

It seems to me that such a knee jerk reaction and placing half thought out
measures in place almost does more harm than good in that it leaves people
with a false sense of security. Take the following code as case in point;

function IsSQLInject(input) {

        var listSQLInject =
"cast,exec,execute,sp_executeSQL,revoke,grant,select,insert,update,delete,dr
op,--,'";
        var arraySQLInject = ListToArray(listSQLInject);
        var i = 1;
        
        for(i=1; i lte arrayLen(arraySQLInject); i=i+1) {
                if(findNoCase(arraySQLInject[i], input)) return true;
        }
        
        return false;
}

Running this function over any user input scope will flag every input that
contains one of the listed strings, i.e. 'Casting sugar', 'selectable
criteria', 'Name: Grant Thompson', so on and so forth...

But at least you're secure, right?

Dr/*foo*/op table orders;

The simplest obfuscation of the command using basic tools and the function
is rendered useless.

Conclusion? You're stopping legitimate use and still leaving a wide open
door to any hacker willing to put in 30 seconds effort. How long until
someone rewrites the current attack pattern and uses the above method to
bypass all of the shiny new keyword scanners? Dec/*can't see me*/lare @s =
.....

That's all without even touching upon encoding.

I'm not claiming to have the ideal patch, I'm not even claiming to have been
the first to notice these things - posts are on many CF blogs detailing
these issues in a far more articulate manner, but I think that advocating
simple keyword scanners in this list is irresponsible, bad advice can be
worse than no advice at all. All 'senior' CF programmers either do, or
should know better.


Please note that I mean no offence to anyone on this list (or anywhere else
for that matter).

Regards,
Gabriel



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to 
date
Get the Free Trial
http://ad.doubleclick.net/clk;203748912;27390454;j

Archive: 
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:309562
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4

Reply via email to