On Sun, Aug 31, 2008 at 1:49 PM, Stut <stuttle@xxxxxxxxx> wrote:
> Good points all, but I'd add two more from my own collection...
>
> 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.
This one would be a little difficult for the team I work with.
Basically I do all back-end type stuff and show front-end people how
to do stuff. The front end team uses Dreamweaver for doing all their
design, etc. I'm not really into making more work for myself than I
need to. ;) Perhaps a little output buffer/using dom to manipulate
the names could work so it is transparent to the team. I'd have to
give this a little more thought. Perhaps this could just be a
technique on the more popular sites that get spammed more. At least
the idea is in my head moving forward.
>
> 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.
That is a great idea and I'll see what I can do to put this into the
code. Should be easy enough.
Thanks for the tips!
>
> -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
>>
>
> --
> http://stut.net/
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
