homepage Welcome to WebmasterWorld Guest from 54.205.242.179
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Pubcon Website
Home / Forums Index / Code, Content, and Presentation / Perl Server Side CGI Scripting
Forum Library, Charter, Moderators: coopster & jatar k & phranque

Perl Server Side CGI Scripting Forum

    
Is this a possible way to protect against spam from Formmail?
penstaar




msg:3893072
 5:41 pm on Apr 15, 2009 (gmt 0)

Hi all,

I apologize in advance if this topic has been beated to death but, I can't find an answer on here to my specific question.

Firstly, I am not a programmer. I know a laughable amount, but I've read through and edited the parts of Matt's formmail that I need to in order to get it to work.

So it's working now, but I know from past use that my client will receive lots of spam submissions.

Would it be a valid way to protect from spam to add a field on my form such as What is 2+2 and then add a subroutine into Formmail.pl to check if that value is 4?

I thought I might be able to find someone whose done that, but haven't seen it used yet.

Does anyone know if that would work, and (lol) what the Perl code should look like to do that?

Thanks in advance!

 

rocknbil




msg:3893118
 6:29 pm on Apr 15, 2009 (gmt 0)

The trivia "challenge/response" approach is widely used. Some swear by it. It's definately better than a capckha. It may solve your problems.

Or, it may just stop them for only a little while. IMO, anything that requires "extra work" by the user is too much. It's not their job, it's our job as programmers to plug these holes. Front - end "patches" like these are just that, duct tape on an issue that really needs to be fixed at the root, in the form processor itself.

I can't help you configure Matt's script as I (like most of us) grow my own and am not real familiar with open source solutions. It shouldn't be too difficult to do, but you will have to get your hands dirty- or pay someone to write you a secure one.

A down-and dirty answer: if the incoming variables are stored in %FORM,

unless (($FORM{'trivia-q'} == 4) or ($FORM{'trivia-q'} =~ /^four$/i)) {
print "content-type:text/html\n\n";
print "You lose. Poof.";
exit 0;
}

penstaar




msg:3893149
 7:18 pm on Apr 15, 2009 (gmt 0)

Thanks rocknbil.

I understand your argument and this will be a temporary fix until I get the real programmers involved during the upcoming site redesign.

It works like a charm for now!
Bless you for helping random strangers.

MichaelBluejay




msg:3894225
 1:57 am on Apr 17, 2009 (gmt 0)

There are actually two kinds of problems with formmail spam, and trivia solves only one of them. It (usually) solves the problem of the site owner getting spam. But what about spammers hijacking the form to send out spam to thousands of other people? To avoid hijacking:

(1) Either hard-code the To: and Subject: values into the script (don't get them from the form input), or else do some error-checking on the To: and Subject: values passed by the form input.

(2) If you're sending the visitor a copy of the message that was entered, then likewise do some error-checking on the visitor's email address.

(3) That error-checking involves aborting if any of the above fields contain a \n or \r character, or if the email addresses contain , or ; characters.

(4) I also abort when the message contains HTML tags, especially <a href> tags. In fact, that pretty much solves the first kind of problem for me, generally, without the need for a CAPTCHA.

coopster




msg:3894472
 11:31 am on Apr 17, 2009 (gmt 0)

>>especially <a href> tags

Excellent idea.

rocknbil




msg:3894746
 5:04 pm on Apr 17, 2009 (gmt 0)

Michael . . . sorry man. :-)

(1) Either hard-code the To: and Subject: values into the script (don't get them from the form input), or else do some error-checking on the To: and Subject: values passed by the form input.

Any mail header - ANY - can be malformed to do this:

$FORM['subject'] = "Subject:Test\nBCC:email1, email2....."

In truth, \n\r are not used - this is for demo only, see below. You get one spam, AOL gets a thousand. Poof, you're on an RBL.

(2) If you're sending the visitor a copy of the message that was entered, then likewise do some error-checking on the visitor's email address.

Agreed, but always send this email from a no-reply address. Some spammers will just submit a form to get your email, then they no longer need to hack your forms. You're hosed.

(3) That error-checking involves aborting if any of the above fields contain a \n or \r character, or if the email addresses contain , or ; characters.

Per the comma or semicolon: Some "Internet Savvy" web users are attuned to the knowledge that many systems accept multiples as comma or colon separated lists. So to avoid offending these, just split it off and take the first address, killing the others silently.

Per \n\r: Spammers aren't that dumb. :-) They use hex or octal characters for these, sometimes convoluting it to the point of encoding the encoding to get past the first layer of filtering. The solution to all this is much more simple:

Accept only what you want. THROW EVERYTHING ELSE AWAY.

Your first pass of defense (AFTER the spam check mentioned below:)

foreach $v (keys %FORM) {
$FORM{$v} =~ s/[^A-Z0-9\.\,\-\%\@\s+]+//ig;
}
I may have missed a few above, example only . .

You would then go on to clean up/check the email, and personally I swap out "%" for the word "percent" to avoid further encoding attempts.

(4) I also abort when the message contains HTML tags, especially <a href> tags.

What about [url=.....?
[a href=.......?
[ name="something" href=......?
[link=....?
%5B URL....?
Raw [....?...]
%22%3E%3Cscript%3E . . . cross site scripting?

If you haven't seen these, you will. :-)

There is no legitimate reason for a contact form to contain a URL. Not one. If it's a link exchange form, you allow a link only in that field, and examine it like a microbe.

Generally I log first, and in my log routine, I look for these. This is a little "backwards" to my response to #3 - keep only what you want - but I like to do it this way to get rid of the most common attempts. Link dropping is the worst.

Out of all these, logging is the most important. Log your raw input, I can't say it enough, this is different than what you get in server logs. Kill the spam silently, review the logs, know thy enemy . . . . . . and you will stop them.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / Perl Server Side CGI Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved