Spam-proofing "Plans"

The Saga

As mentioned on the previous page the Troop 53 calendar was first spammed in late February 2008. At that time the calendar was being run by version 6-point-something of Plans. I had been very reticent to upgrade because I knew it would be a long and time-consuming task to get everything the way I wanted it and to match the look and feel of the existing calendar. So I hacked the code of plans.cgi and found a couple of lines around line 225 that had something to do with the Add Calendar form. Once commented out, the form didn't show up anymore. That didn't stop requests for the form, but those requests hit a page with no way to submit anything, or so I thought. Every once in a while a POST request would be made, although I have no clue how.

I also thought that I really didn't need the new_calendars.xml file since I didn't need any new calendars. So I deleted it from the site. That caused Plans to throw errors on accessing certain things, so I put it back but CHMODed it to Read-only (444 or -r--r--r--). At least if a POST request was made they couldn't write to the file so the information they submitted wouldn't be viewable.

After a few days of increasing attempts to spam the calendar, I went to the Plans website and downloaded the latest version thinking it might have more security built into it. After getting everything configured the way I wanted it and making it "live" the POST requests returned. And the frequency of requests increased even more. I would look through our log files and find the most eggregious IP ranges and block them through .htaccess but realized I was fighting a losing battle. Plus I was blocking off access, both legit and non-legit, to our site from large parts of the world. It also only blocked about 10% of the requests. IP-based blocking was definitely not the answer. I looked through the Plans forum and found only one reference to spamming through that form and it was from February 2007 (I later found another one from March 14, 2008). At that time the developer said he'd add the administrator password field to the form to stop the spam from appearing. Well, that was only part of my problem. I wanted to block all requests for that URL and I knew it would have to be .htaccess-based.

After doing a lot of searching I tried to block based on the requested URL, and that didn't work. But then again, I may not have written it correctly since I'm definitely not an .htaccess guru. I'm good at copy/pasting, and can kind of figure out what's going on, but .htaccess uses Regular Expressions (RegEx) to define its commands and I have almost no clue about RegEx. Eventually I found something about QUERY_STRING, and since the part of the form URL that's unique is the end of the query string ("action=add") I researched that. After some more reading I found some code that looked like it might just work, so I copy/pasted it and edited a little. After uploading I found our entire site broken! Well, it turned out that I left an exclamation point in front of action=add (RewriteCond %{QUERY_STRING} !action=add), which says to the server, "if the query string does not contain action=add, do the following." Removing the exclamation point fixed that and solved my problem.

Now, this is not a panacea. Requests are still being made at a prodigious rate. But it did cut in half the number of them since the form cannot be filled out and submitted with a POST request. It also cuts way back on bandwidth used for the calendar which may, on some hosts, get you into trouble.

Hopefully, this will help others. I've noticed quite a number of BSA-related websites that have been spammed as well as university and other non-profit sites. One university "View Pending Calendars" page had well over 2 Megabytes of spam submissions posted!