views:

68

answers:

3

We're having an issue on one of our fairly large websites with spam bots. It appears the bots are creating user accounts and then posting journal entries which lead to various spam links.

It appears they are bypassing our captcha somehow -- either it's been cracked or they're using another method to create accounts.

We're looking to do email activation for the accounts, but we're about a week away from implementing such changes (due to busy schedules).

However, I don't feel like this will be enough if they're using an SQL exploit somewhere on the site and doing the whole cross site scripting thing. So my question to you:

If they are using some kind of XSS exploit, how can I find it? I'm securing statements where I can but, again, its a fairly large site and it'd take me awhile to actively clean up SQL statements to prevent XSS. Can you recommend anything to help our situation?

A: 

How is your captcha implemented, and the fact that the user has successfully completed it flagged? I mean, I assume it's not just a "captchaokay=1" parameter in the POST. :-) Are you using a tried-and-tested captcha solution like reCAPTCHA or similar?

T.J. Crowder
Using Securimage Captcha (http://www.phpcaptcha.org/) for now, but certainly not opposed to switching to reCAPTCHA.
Mike
+3  A: 

1) As mentioned above reCAPTCHA is a good start.

2) Askimet is a great way to flag spam before it is published. It's what Wordpress uses to stop spam and it is extremely effective. You then could reject or queue the entry for moderation based on the results. It's API is ridiculously easy to use, too. (I have PHP code if you need it). You might need a commercial license although I am sure you can get started using the free version.

3) Verification of email addresses is definitely a good idea as it requires a valid email account which many spammers do not have. Just make sure you make verifying the email address easy as if it is too difficult it can turn legitimate users away as well.

John Conde
+1  A: 

If the bots were exploiting a hole in a script somewhere, there should be evidence of that in the logs. Check for direct POSTs to user creation scripts and the journal entry creation scripts without the usual "normal" surfing activity prior to the hit: The bots may have trolled the site only once and are bypassing the step of pulling down the forms and pretending to fill them in. Look for GET requests with obvious XSS-type data in the query strings.

You could also embed a random token in an hidden field within the forms and require that token to be present for the activation/posting to go through. If the bots only parsed your signup scripts once and are doing direct posts, this will stop them in their tracks until the bot creators catch on and look for the token. But it would give you some breathing space to implement a better system.

If your user account tables don't have some kind of time-of-creation time stamp on them, put one in and have the server create the timestamp, not your user scripts. This way you can narrow down the time period(s) to scan the logs for bot activity and see what they're doing. And if nothing else, you could block the IPs the bots are posting from.

Marc B