Category: Weblogging

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?)

Recovered from the Wayback Machine.

Seems to be a technology day today.

Phil caught a comment spammer who was trying to dump spam comments in all of his posts. This process would work within any weblog that sequentially numbers weblog posts (ie Movable Type).

I’m going to try and tweak my mt-comments.cgi to stop POSTs from pages outside of my root URL. This is my way of warning you all that the comments, web pages, weblog may be a tad more behaviorally challenged than normal.

Update: I added checks on referers and this will prevent posts from locations other than my own weblog server. Unfortunately, as Phil pointed out, http referers are fairly easy to fake. I also wrote a test script that did so, and my checks failed to catch a ‘fake’ referer.

Still, it’s a start…

If you attempt to post a comment and fail, please send me an email and I’ll check to see what the problem is. Unless, of course, you’re the spammer. In which case: Eat dirt and die scuzzbucket!

Ahem. Thank you.