Stut schreef:
Good points all, but I'd add two more from my own collection...
nice posts, both of you! it's time I rewrote my general form submission
routines ... I'll be taking all your suggestions and putting them into
practice (in so far as I don't do so already).
free specs for better code, nice :-)
I have another trick to add, off the top of my head: namely checking all
submitable field values for the existence of things that look like email headers
(for those bots that try to massspam via header injection), no real
user will ever send you a comment (or anything else) that contains email
headers as legit content ... if you ask me anyway.
Field names
Don't name fields things like name, email, address, postcode, message,
etc. Instead name them a, b, c, d, e, etc but name your hidden field
email. That should provoke most bots into changing that value and leaves
others unsure what to put where so they ignore the form.
Time it
If you have a session or cookies availble, store the time that you
displayed the form and check to see how long it took the "user" to
submit it. If it's less than a couple of seconds you can bet it's a bot.
-Stut
On 31 Aug 2008, at 18:25, Eric Butera wrote:
I guess I'll chime in with my experience on this problem. For the
past 2 years I've been using a form processor script I wrote on all
the client sites for my company. I developed it at first to handle a
simple set of functionality that hit 90% of the requirements of
contact forms. It can handle any input field and will send emails,
log the results, or anything else you want with a simple plugin hook
architecture. It is deployed on hundreds of contact forms across
dozens of different websites.
I'm happy to report that most of the spam across the board has been
stopped. All without a single CAPTCHA. When we spot a problem, I can
update our one form processor and then all of the scripts are
protected against the new attack vector. Plus when there is a very
specific case I can use the plugin setup to really get specific in my
rules.
Here are some of the concepts that it employs. Please keep in mind
none of this is a 100% and each can be easily bypassed, but together
they are fairly good. If a human is doing the spam manually, then
there's nothing you can do. :) Also it should be noted that if any of
these requirements fail, then I simply re-display the form with a
message that explains why to the user so that legitimate users will
see what went wrong. Again this aids in allowing spammers to find a
way around, but that is always our burden.
Valid Email
I require an email address in a specific input field and use the
PEAR_Validate function to validate the existance of the domain name.
Also there is another thing where I can say do not allow email from
this domain as some spam software will auto fill in the current
hostname.
Honey Pots
This is a two step process. First I have a hidden form field that has
a specific value in it. If this value is tampered with, then I reject
the form. The second form field is inside of an html comment. If
that value is posted, then I reject the form since it shouldn't exist.
Blacklisting
There are a key set of words that I block.
array('to:','from:','cc:','bcc:','href=','url=')
Require Cookies/Sessions
Most spamming programs I've seen are stateless. So by simply
requiring it accept a cookie foils quite a bit of them.
Max @ limit
Another little trick is to limit the number of @ characters that can
exist within the contents of the post variables. This catches quite a
few submissions.
Define form fields
An optional feature is to enable something to define each input field
that should exist in the post array. Then when the form is posted I
check the defined post array against what has been posted. If there
are extra post fields, then I re-display the form since it is probably
a spam bot just blanket testing forms.
One thing to keep in mind is that this is in use across a lot of
different sites. Not one specific type of site or service is in use
here. Perhaps if someone had more incentive to crack on one of our
forms I'd have more issues. It is hard to say. All I know is that it
has worked really well for my needs, maybe it'll work for someone else
too.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
