Day: October 29, 2002

Recovered from the Wayback Machine.

Both Sam Ruby and Phil Ringnalda had good advice — don’t spend a lot of time on developing a solution to fixing the comment spam problem. Whatever I can do within the form, it’s a relatively simple matter for a spammer to read any form value and duplicate it in his spam blast.

I appreciate both their help in gently pointing out that I was spinning my wheels (but I have to get practice for ice driving).

So, here’s a quick fix — it will keep out the lightweights at least. It’s a start as other efforts are underway.

This approach will require you modifying the following MT templates:

Individual data entry
Comment Listing Template
Comment Preview Template
Comment Error Page

You’ll be adding the following field, on the line before the </form> tag:

 

<input type=”hidden” name=”snoop” value=”goaway” />

 

You can change both the name and the value field, as long as you’re consistent with the name throughout the templates and the code.

Next, open your mt-comments.cgi (or mt-comments.pl) file and add the following code just after the “use strict;” line:

 

use CGI qw(:standard);

if ($ENV{‘REQUEST_METHOD’} eq “POST”) {

my $data = param(‘snoop’);

die unless ($data);
}

 

Most everyone should have the CGI.pm perl module installed. Make sure to change ‘snoop’ to whatever your little secret field is (let’s all use different fields, make the spammer’s job a little tiny bit harder.

That’s it.

What happens is that when you post a comment, the code checks for a form field of “snoop”. If it doesn’t find it, it dies. Nothing fancy at all. This will show in your error log or web log file as a premature end to the script. It doesn’t prevent others from using the application, and doesn’t crash anything.

Again, this isn’t fancy, but it’s a start. Holler if you have questions. If you’re uncomfortable modifying mt-comments, let me know and I’ll help you. If you have a better solution, or see problems with mine, please let me know.

Again — thanks to Phil and Sam for advice, help, suggestions.

Update:

Mark has put together a nice re-cap on the whole comment spamming thing. What I just created is a ‘club’. I’m going in for an interview tomorrow and when they ask me what was the last application I worked on, I’ll answer “A club”. .

Recovered from the Wayback Machine.

In regards to the comment spam problem mentioned earlier, one idea kicked around was checking the http_referer to make sure that the comment post came from the same server as the form.

We talked about the possibility of empty http_referers — not all browsers send a referrer and proxy servers can strip out the referrer. The solution would be to allow empty referrers in addition to referrers from the server. Unfortunately, though, allowing for empty http_referers will also allow in the comment spammer.

The reason why allowing empty referers opens the door to the spammer is the comment spamming code would invoke my comment code directly, not through a link from an HTML page. In this case http_referer would be empty.

I could become more restrictive, remove the permission for empty referrer, but if I do, I won’t be letting some of you through (as you’ve been kind enough to let me know via email tonight).

Sam Ruby had some good ideas such as putting hidden form fields into the comment forms and testing for these and this will be a next step. This means adding form fields to all templates related to comments, and then adding code to mt-comments.cgi. Doable, and many appreciations to Mr. Ruby for excellent ideas. (If you don’t know Sam, he works on some weird sounding things such as “Comanche” and “SOUP” — stuff like that).

A really nifty and difficult to crack approach (IMO) would be to take the person’s login name and the comment id for each comment and use these to create an encrypted value. Stuff this into an HTML form field. When the form is processed, test to see if the encrypted value checks out. If the person’s login name isn’t exposed, which is should NEVER be, it becomes a ‘key’ for the encryption, easily accessible to the MT program and the MT user, NOT to the spammer. And the different comment identifiers would make sure that the encrypted values changed with each comment.

Only problem with this solution is it would require cracking into the MT internal code.

Question: what do you think of this as a solution, and is it worth the time to do it?

(However, by now, Phil or someone else of like cailber will have found and coded a solution and have it half way distributed throughout the world. I should just leave these little challenges to others — what do I know?)