Fighting spam on a form besides captcha...

[Jim R]

I have a form on my site, and captcha isn't really working very well at keeping spam out.  I put a hidden field in my form, and that was doing the trick for awhile, but while not as much as before, I was still getting an occasional spam submission.

 

I thought changing the $_POST label would help, but now it won't work.  I made no other changes than to the form and the code processing the form.  

Form HTML:

<input name="name" type="hidden" />


**** php file ***

if (ISSET ($_POST['name'])) {
	echo 'Thank you for playing';
}


else

{

//process form

}

It was "email2".  Changing it to "name" has caused it to not work, and no other field is called "name".  

[Jim R]

Just to clarify, that method allowed 86 legitimate registrations to go through, and only in the last couple of days had spam started showing up.  

[darkfreaks]

http://www.google.com/recaptcha

http://akismet.com/

[mac_gyver]

the logic you showed in the first post is backwards. if the $_POST field is set, you echo a message, else you process the form.

 

this might be an actual person and no amount of captchas/hidden fields that should/shouldn't be filling in will help because it is a person using your actual form.

 

what occurs for a successful submission that would be of benefit for a person/bot script? is an email sent to the arbitrary address that was entered that also might contain spam content that was submitted? is the person/bot then able to post spam content on a forum?????

 

what's the actual spam content vs normal content, so that you might get help in detecting/filtering it out?

 

are you logging all the available information about the submission (date/time, ip, all headers in the request) so that you can try to determine where they are being sent from/through and how far a part they are so that you might be able to detect and filter them out?

[Jim R]

The logic is that if the spam bot populates the hidden field, the form isn't really processed.  I think I picked up the idea from here somewhere, but I didn't follow or comment on the topic, so I can't find it.  I did search for it before I posted this topic.

 

 

The form is taking information from registrants to participate in a basketball league.  Upon successful registration, their name is entered into the database and an emails are sent to them and me.  Their names are also put on a published list.  I had it up from July 6 to August 13, two days ago, and it was working.  Until August 8 or 9, it was keeping spam out, while allowing successful registrations through.  That has changed this week.  

 

What I'm getting with the spam is gibberish information.  I think I can detect a pattern to what it's doing, typically nameFirst = nameLast, but I haven't had any registrations the last two days because of the issue I posted about.  It hasn't let any registrations through since I made my change.  

 

All I did on the 13th was change the input name of the hidden field from email2 to name, and somehow it's not working anymore.  I made no other change to the form, and I made the same change to the php code processing the form.  I was hoping changing the name of the field would confuse whatever spam bot had found it's way through.

 

 

I'm not logging any headers.

 

 

 

@darkfreaks, my reCaptcha is through Google

[TOA]

Try changing the name back to email2 and see if it goes back to working..

[Jim R]

I tried that before even seeking help.

[TOA]

Then that's not what broke your script. You had to have done something else

[Jim R]

I appreciate that thinking, but I didn't change anything else.  Even if I had, the ISSET is the first thing on the php file processing the form.  It's not getting past the IF...ELSE.  

 

Also, mismatching the variable allows the form to work, so once it gets past the IF...ELSE, it works just fine.

[TOA]

By what you're saying, that all you did was change the name of a variable, there's no way it wouldn't work by changing it back. I thought about a reserved word clash but you said changing it back doesn't make it work again. It can therefore NOT be the name and you HAD to have done something else. That's logic. I'm sorry you disagree.

 

Maybe if you post more code, it would help...

[Jim R]

I understand what you're saying, but keep it on simple terms here.  I have a form with a hidden field called "name".  The form sends the user to enter.php where it's processed.  The first thing enter.php does is...

 

 

<?php
// Make sure this person is real


if (ISSET ($_POST['name'])) {
echo 'Thank you for playing';
}


// If so move on


else


{


$nameFirst = $_POST['nameFirst'];
$nameLast = $_POST['nameLast'];
$nameParent = $_POST['nameParent'];
$email = $_POST['email'];
$addressHome = $_POST['addressHome'];
$cityHome = $_POST['cityHome'];
$stateHome = $_POST['stateHome'];
$zipHome = $_POST['zipHome'];
$phoneHome = $_POST['phoneParent'];
$phoneMobile = $_POST['phoneMobile'];
$school = $_POST['school'];
$grade = $_POST['grade'];
$coachSchool = $_POST['coachSchool'];
$feet = $_POST['feet'];
$inches = $_POST['inches'];

From there it goes on to check if the Registrant is in the database.  If so, it updates it.  If not, it inserts him.  Then it sends out emails and redirects the Registrant to the payment page.  

 

 

Now, if I change "name" to "name1", the form now works because "name1" doesn't get set because there is no "name1" in the form.  Registrant information gets sent to database, emails get sent.

[Jim R]

OK...I may have found out the problem.  And yes, I'm a moron, and as I've posted on here several times this is why coding for a living would  a)  not be an option, and b)  drive me insane:

 

The problem:  

The field names were mismatched all along  "email2" on the form, "Email2" on the enter.php.  

 

So when I changed both to "name" it 'stopped' working.  It never worked.  

 

However, I found a similar solution, and it looks like I did it wrong the whole time:

 

http://www.webdesignerforum.co.uk/topic/68584-anti-spam-form-without-captcha/

 

 

Basically, I needed to set up the hidden field with an empty value = '', so if it remained empty keep going, but if a spam bot fills it, stop and say "thanks for playing".

 

Luckily my wild goose chases only happen about twice a year.  One time we had this long a$$ discussion with two or three guys trying to help.  Each one of us saying there is no reason this shouldn't work.  It came down to having a comma instead of a period.  Like anything, if you get enough eyes onto the subject, eventually you'll find the solution, even if it makes you look harder at your own code.

 

I had kept the php files open since I made the changes, so I was able to CTRL-Z back to where they were before the change.  That's when I noticed the difference in the capital E in Email2.  

 

Thank you for your time.  I've tested the solution I linked, and it's working great...at least in terms of letting the form go through.  We'll see how it does with spam over the next few days.   

[sKunKbad]

I've been successful blocking most spam with a CSRF type form token. Making javascript mandatory also gets rid of a lot of bot related spam, but the token is the real gem when it comes to blocking bots. You just set a random value in the form and in a cookie that only lasts for one request (the POST). If the value in the form doesn't match the value in the cookie, then you know the form didn't POST from a real browser.

[mac_gyver]

now that you have explained that the (uncommented) code you posted was the code intended to filter out bot submissions, all text, textarea, and hidden form fields are set if the form has been submitted. the only types of form fields that might not be set when a form has been submitted are radio-buttons and check-boxes. so, your using of isset() will always be true when the form has been submited. you need to test for empty/not empty or test for an empty string or not an empty string in that field.

 

if that posted logic allowed the form submission to be processed before you changed the name of the field, it was because you had a mis-match in the field names and the field your php code was testing didn't exist at all and wasn't set, ever.

Edited August 16, 2013 by mac_gyver

[Jim R]

Yes, that makes perfect sense, and in having mismatched variables, it 'worked'.  It was weird though, I went awhile with no spam after having some, then it returned a few days ago.  I'll be curious to see how long I go now without spam, but there are a couple of patterns the spam is inputting that I could deal with as well should not the do the trick entirely.