Someone from IP 217.218.155.73 attempted to hack our site through some of the forms. Truth be told, I don't think the kiddies were truly attempting to hack the site. Based on evidence in the log files it looks more like they were trying to find code to exploit for the purpose of spamming. Still, without more investigation I can't say whether or not any real hacking attempts were made.
At any rate, the pages that were obviously toyed with were the search redirector (search.asp), the page survey (surveypage.asp), and the one-time notification page (notify.asp).
The search redirector does not really provide much of a vector for exploitation. It's main purpose is to redirect to the AAAS search and so there isn't much available for exploit. Some of the variables can be toyed with to crash the script, but that's about it at this point. I'm not too worried about it because the script won't crash unless the user makes an attempt to cause one.
The one-time notification does provide for a little more opportunity for exploitation since it connects to the MS SQL server. Most of the script is fairly benign, but an SQL INSERT is used. To mitigate any possible hack attempts I'm SQL encoding any user-supplied input. On the plus side, even if some malicious SQL code is run via the script the connection to the database is with a limited access SQL account.
The page survey proved to have a bit of a security oversight in the coding. Luckily the database used for that is MS Access, leaving fewer options for the kiddies. The page does access the database using a simple SELECT statement, however, which left the page open to possible hacks. I modified the statement so that user-supplied input is now SQL encoded.
While SQL encoding user-supplied input is a good start I'm not entirely certain that it prevent the database from being hacked. I'll need to do some research to see if there are any known problems when using the MS SQLEncode() function. Probably an even better strategy would be to plan on dropping direct SQL statement execution and move towards stored procedures or parameterized statements.
I'm going to check for any further hacking from the IP range associated with this probe.
Update 2005-10-13:
Upon further checks I didn't really find any other hack attempts of note. There were more of the same hack attempts from different IPs. We're likely listed in some kiddies search list. On the positive side, it pointed out some possible security lapses on those scripts mentioned.
