Posts Tagged ‘SomeCustomInjectedHeader’

Protecting your events against spam

It can happen at any time.  You’ve opened your event for registrations and you are suddenly inundated by obviously fake users and incomplete transactions.  Spam is everywhere (and we don’t mean the food).  It’s in your inbox, it’s in your comments, and it’s in your events.

Where does it come from?  A lot of spam — particularly the type of spam that fills up contact forms (and event registration forms) — comes from a specific kind of script designed to identify potential security holes in your site like this one.  These types of applications are designed for admins to check their site before deploying it live, but in the wrong hands can be run on a site, or a series of sites, automatically, and — at the very least — inject huge dumps of worthless code into your database and — at worst — obtain database access and the ability to manipulate the data stored on your server.  There are a few different ways you can protect yourself, your data and your event site against spam registrations.

The first option is the best solution and most recommended: Enable the mod_security module on your Apache installation. Most spam registrations come from bots or scripts that crawl a site looking for forms and fill them with data remotely (e.g. it’s not actually done by a human visiting your site, but a machine that is executing your code without ever actually hitting your site). The mod_security module protects your site against these kinds of remote submissions. If you do not have access to configure what Apache modules are enabled or disabled on your server, you might ask your webhost if it is possible to enable it. In my opinion, this should be on by default on all Apache servers (and IIS and nginx — which it also supports).

If enabling mod_security is not a possibility in your environment — either because you do not have access to your Apache configuration or your host is not able or willing to enable or install the mod_security package — you can use reCAPTCHA to require that attendees fill out a CAPTCHA form before their registration is recorded. reCAPTCHA is part of an initiative to digitize books, newspapers and radio recordings.  Every time you enter a response in a reCAPTCHA form, you are helping the software identify real words that a computer was unable to read.  Since the words that appear in a reCAPTCHA form have already failed sophisticated OCR technologies to translate them into text, spam bots aren’t likely to be able to read it, either, so you’re protecting  your forms when you require a CAPTCHA for verification.  While this can be arguably somewhat more annoying to the user, it will thwart any bot attempt to fill the form with garbage.  For more information about how reCAPTCHA works, check out the reCAPTCHA site.

You can also use the Event Espresso WP User Integration plugin to make all your events member-only and require your users to log in using the built-in WordPress user registration system. Even if you do not have some form of human verification on your site’s registration process (this is not recommended, especially if you’re already getting hit by spam registrations), the additional step that a bot would need to go through of registering for a site, and then logging in before it is able to register for an event means that you are safeguarding your events against a potential attack by a script. The benefit of this over using reCAPTCHA is that there are a number of options in addition to reCAPTCHA in which user registrations must verify that they are not a bot by answering an admin-defined questions like “what color is the sky” or “what is two plus four” as opposed to trying to decipher a hard-to-read CAPTCHA image.

Event Espresso runs sanitization and data validation checks on all information that is stored in the database.  This means that anything one of these scripts injects gets cleaned before being stored in the database, which, in turn, means that none of the data that gets dumped your system will be likely to cause any real damage to your site or expose any hidden passwords or personal information.  However, dealing with a site that has been hit by thousands of fake user registrations can be tedious and time-consuming.  Protect yourself, and your valuable time, by checking with your host about whether mod_security is enabled.  If you are seeing registrations to your events that are obviously fake, take one of the precautions mentioned above and save yourself a lot of headache.

For more information, head over to the support document for anti-spam and reCAPTCHA.

Tags: , , , , , , , , ,
Posted in Event Planning | No Comments »

Event Espresso