Skip to content
This repository has been archived by the owner on Jan 14, 2019. It is now read-only.

Submission Plugin: Simple Honeypot Spam Detection #61

Merged
merged 1 commit into from
Oct 30, 2013
Merged

Submission Plugin: Simple Honeypot Spam Detection #61

merged 1 commit into from
Oct 30, 2013

Conversation

dweidner
Copy link
Contributor

@dweidner dweidner commented Oct 8, 2013

Many different techniques for spam protection exist out there (have a look on the great article of David Bushell on Smashing Magazine for an overview). The honeypot trick is probably one of the easiest methods to implement. Using this technique a form field is introduced which is hidden from users using CSS. Weak spam bots will probably fill out those fields allowing us to distinguish between input from humans and bots.

This pull request implements a simple option that allows developers to specify the name of such a honeypot field in the options. If a value for the specified field is given, the submission of the form will be canceled and the success callback will be triggered directly. This way the spam bot is given the illussion everything went well. In the success callback the isSpam method can be used to implement different behavior for spam messages and valid requests.

In case of the contactform spam bots will be simply redirected to the url given in the goto parameter without sending the email to the recipient.

bastianallgeier added a commit that referenced this pull request Oct 30, 2013
Submission Plugin: Simple Honeypot Spam Detection
@bastianallgeier bastianallgeier merged commit fdebb9a into getkirby-v1:master Oct 30, 2013
@bastianallgeier
Copy link
Collaborator

It took me way to long to accept this PR, but this is great!! Thanks :)

@dweidner dweidner deleted the honeypot branch October 31, 2013 11:18
@piersolenski
Copy link

This looks great, could you give a little more information on how to implement it?

@dweidner
Copy link
Contributor Author

Sure, you could have a look on the current dev branch of my online portfolio. It contains a snippet using the contactform plugin: https://github.com/dweidner/danielweidner.de/blob/master/site/snippets/widget/contact-form.php

Here are some further explanations and details:

$form = new contactform(array(
    [...]
    'honeypot' => 'email-repeat-142'
));

In the honeypot field you should specify the name of the field that represents the trap for our bots. It is important that the value equals the name of the input field. It is good practice to give it a name that does not raise suspicion on the side of the bot (like spam-protection). A problem though could be the auto complete features of modern browsers. They might fill in the field, even though it is hidden using css. To avoid this I use a line of javascript which turns this feature off:

document.getElementById('cf-email-repeat-142').setAttribute('autocomplete', 'off');

For browsers that have JavaScript turned off I simply dont hide the field group containing the honeypot. Speaking in CSS this would probably look something like this:

.js .field-group--alternate {
    display: none;
}

Again I have chosen a class name which does not indicate what is actually going on. Hope my snippet helps to clarify the concept.

@piersolenski
Copy link

Thanks! :-)

@piersolenski
Copy link

This has served me really well, however, recently I've started receiving a lot of junk again. Any ideas why or how to further secure it? Thanks

@dweidner
Copy link
Contributor Author

Hey Piers,

there are a variaty of additional methods that could help to lock out spam bots. One method I first read about is described in a blog post by David Walsh: https://davidwalsh.name/wordpress-comment-spam

His concept assumes that most users browse the web with JavaScript enabled (in contrast to most SpamBots). As a consquence you could add additional post data on submission via JavaScript. On the server side you only process the form submission when this kind of additional post data is available.

Another, more user friendly, idea would be to measure the elapsed time between the page rendering and the form submission. This assumes that a "regular" user would require at least some time to fill out the form, before sending it. You could use PHP to include the time the page was rendered in a hidden field and calculate the difference to the submission time before processing the input.

Another concept I read about was to change the name of the fields with each rendering of the page. You could use some hashing algorithms with a secret token to encode the name of such a field. This may confuse Bots as they do not know what to fill in. Don't know how effective this method is, though.

You can have a look into the Controller of a comment system I am writing for Kirby 2. Some of the described methods are implemented there as well (in addition the plugin uses the Akismet API to detect obvious spam attempts).

Unfortunatly spam protection is a difficult field and bots are getting smarter with each day :(. Hope these ideas can help somehow.

@piersolenski
Copy link

Thanks @dweidner, really comprehensive and helpful answer. Will look into all of the above!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants