So I'm running some old web software that has possible vulnerabilities. Here's a log line with the hack attempt. Fortunately, it didn't seem to work, but it was attempting a SQL injection attack, putting something into the database.

0.0.0.0 - - [11/Feb/2011:16:52:49 -0800] "GET /archives/archive_by_id.php?id=1752&category_id=999999.9+UNION+ALL+SELECT+%28SELECT+concat%280x7233646D3076335F73716C5F696E6A656374696F6E%2Ccount%28*%29%29+FROM+la_i
ndymedia_org.dbadmins%29%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x3130323
5343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536-- HTTP/1.1" 200 27883 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT
5.1; SV1; .NET CLR 2.0.50727) Havij"

I'm still trying to understand what's going on, but it could have been avoided if the code included a line like this:

if (!is_numeric($_GET['category_id'])) exit;

Presumably, nobody needs to enter the category_id, so there's no need to make a fancy looking error page. Just fail. Same for the id parameter.

Also, another problem I have with this software is that they don't do their input validation at the top of the script. If it's done at all, it's deep inside the code. It's a real debugging headache. I know it harkens back to hated languages like shell scripts and COBOL, but it's best to handle inputs at the top of the file, and massage outputs at the bottom of the file.