Protect legacy ASP applications against SQL Injection by parsing SQL commands.

Posted By: siteadmin on 21/11/2011 10:46:00

This is not the perfect solution. The perfect solution is to rewrite your code, never allowing a user input to be fed into a SQL statement.

However, as we know, the world is not perfect. If you have an old app, maybe very large, with old libraries, and no documentation? Well here is a solution that we have used, that has worked 100% in blocking SQL injection attacks.

It's not free, nor is very suitable for high performance sites, as it will all a drag factor onto your app. But it maybe suitable for some.

Go over to our friends at SQL Parser: http://www.sqlparser.com and buy the parser.

Make a call to this function with every SQL command before executing it.

if ParseQuery(strsql) = 1 then

response.Write("Violation Logged")

response.End()

end if

function ParseQuery(strQuery)

'returns 0 if query OK, and 1 if bad.

dim parser

Set parser = server.CreateObject("gsqlparser_ao.GSqlParser")

parser.CreateInstance 0

parser.SqlText =strQuery

parser.Parse()

for i = 0 to parser.SqlStatements.Count() - 1

if i=0 then

ParseQuery=0

else

'write SQLINJECTLOG

ParseQuery=1

discard= hacklog(strQuery )

end if

set parser = nothing

end function

function hacklog(t)

on error resume next

Set fso = CreateObject("Scripting.FileSystemObject")

Set textStreamObject = fso.OpenTextFile(server.MapPath("\")&"\logs\hacklog-"&replace(formatdatetime(date),"/","-")&".htm",8,true,0)

textStreamObject.WriteLine(t)

'response.Write(text)

textStreamObject.Close ' Make sure you close it or it won't write it!!

set textStreamObject = Nothing

Set fso = Nothing

on error goto 0

end function

Basically what happens here is that when you pass your SQL statements over to the Parser it will count now many Statements are in the Command, as SQL injection involves 'chaining' commands onto the end of your legitimate SQL statements you will always have more than 1 command.

If you enable the hacklog function, it will save the errant commands out to the log and you will be able see the format of the hack attempts.

E.g.

SELECT * FROM COUK_postcodecache WHERE postcode = 'NG21 9BX' ;dEcLaRe @s vArChAr(8000) sEt @s=0x64526f50207441624c6520745f743b635265417445207441624c6520745f7428632076417243684172283830303029293b6445634c61526520407220764172436841722838303030293b6445634c61526520407473207641724368417228323030293b7345742040723d307832303b6445634c61526520637220635572536f5220466f522073456c456354206e616d652046724f6d205b636f756b626564616e64627265616b66617374735d2e64426f2e7359734f624a654374532077486552652078547950653d30783735206f50654e20637220664574436820637220694e744f20407473207748694c6520404066457443685f7374617475733d3020624567496e207345742040723d40722b4074732b6348615228392920664574436820637220694e744f2040747320654e6420634c6f5365206372206445416c4c6f4361546520637220694e7345725420694e744f20745f742076616c756573284072292d2d eXeC(@s) -- And '8'='8'

The long string of numbers is a hex encoded string function used to Inject rubbish into your database.

Enjoy patching your your old apps, and good luck.

Also see our article on cleaning up after a SQL attack at http://www.kbytes.co.uk/Articles.asp?articleid=21

blog comments powered by Disqus

Kbytes Home | Privacy Policy | Contact us | Testing Area