Preventing SQL injection in unknown sourcecodes
March 11th, 2008Wow its been a while since I’ve written something.
There has been a lot going on lately, the RoboCup 2008 robot competition is coming up soon in a month, I’ve been very busy trying to get the robot to work (pics coming soon)…
Anyway, with all this, I haven’t had a lot of time to work on my other sites, and someone just pointed out recently that there is at least on sql injection vuln in one of the sites. Since I didn’t code the site, the whole source code is a mess, 40000 lines of php code mostly showing how NOT to code. So with my time very limited atm, I decided it was time for one of my little dirty hacks. The idea was to write a wrapper function for mysql_query() that would be called instead of the real function, and it would check the query for well known and commonly used methods of SQL injection, like the ‘ OR 43=43, UNION SELECTs, CONCAT, CHAR, –, /**/, # and so on. Most of these could be easily matched with regexes, and the code was ready within half an hour, and it seemed to work very well. The only problem that remained was that it would also match them in strings as well, which resulted in some false positives, especially with characters like # and –. So I decided I’ll write a mini parser that would replace the properly escaped string values in the query with 1 and then do the matching. That got rid of the problem and now it seems to work flawlessly so far.
Right now its still in the “logging” mode, where it only logs if an attempt has been detected, but once I’ve monitored it for a few days and make sure it doesn’t interfere with any of the normal queries, I will put it in the “defend” mode that will ban the user if an attempt was detected.
P.S.: Will try to post here more often
With the robot competition, I got plenty to talk about ![]()
Popularity: 2% [?]
