Better Honeypot Implementation (Form Anti-Spam) - forms

How do we get rid of these spambots on our site?
Every site falls victim to spambots at some point. How you handle it can effect your customers, and most solutions can discourage some people from filling out your forms.
That's where the honeypot technique comes in. It allows you to ignore spambots without forcing your users to fill out a captcha or jump through other hoops to fill out your form.
This post is purely to help others implement a honeypot trap on their website forms.
Update:
Since implementing the below honeypot on all of my client's websites, we have successfully blocked 99.5% (thousands of submissions) of all our spam. That is without using the techniques mentioned in the "advanced" section, which will be implemented soon.

Concept
By adding a invisible field to your forms that only spambots can see, you can trick them into revealing that they are spambots and not actual end-users.
HTML
<input type="checkbox" name="contact_me_by_fax_only" value="1" style="display:none !important" tabindex="-1" autocomplete="off">
Here we have a simple checkbox that:
Is hidden with CSS.
Has an obscure but obviously fake name.
Has a default value equivalent 0.
Can't be filled by auto-complete
Can't be navigated to via the Tab key. (See tabindex)
Server-Side
On the server side we want to check to see if the value exists and has a value other than 0, and if so handle it appropriately. This includes logging the attempt and all the submitted fields.
In PHP it might look something like this:
$honeypot = FALSE;
if (!empty($_REQUEST['contact_me_by_fax_only']) && (bool) $_REQUEST['contact_me_by_fax_only'] == TRUE) {
$honeypot = TRUE;
log_spambot($_REQUEST);
# treat as spambot
} else {
# process as normal
}
Fallback
This is where the log comes in. In the event that somehow one of your users ends up being marked as spam, your log will help you recover any lost information. It will also allow you to study any bots running on you site, should they be modified in the future to circumvent your honeypot.
Reporting
Many services allow you to report known spambot IPs via an API or by uploading a list. (Such as CloudFlare) Please help make the internet a safer place by reporting all the spambots and spam IPs you find.
Advanced
If you really need to crack down on a more advanced spambot, there are some additional things you can do:
Hide honeypot field purely with JS instead of plain CSS
Use realistic form input names that you don't actually use. (such as "phone" or "website")
Include form validation in honeypot algorithm. (most end-user will only get 1 or 2 fields wrong; spambots will typically get most of the fields wrong)
Use a service like CloudFlare that automatically blocks known spam IPs
Have form timeouts, and prevent instant posting. (forms submitted in under 3 seconds of the page loading are typically spam)
Prevent any IP from posting more than once a second.
For more ideas look here: How to create a "Nuclear" honeypot to catch form spammers

We found that a slight (though simple) variation on the suggestions here made a huge difference in the effectiveness of our contact form honeypot. In short, change the hidden field to a text input, and make the bot think it's a password. Something like this:
<input type="text" name="a_password" style="display:none !important" tabindex="-1" autocomplete="off">
You'll note that this mock-password input keeps to the same basic guidelines as the checkbox example. And yes, a text input (as opposed to an actual password input) seems to work just fine.
This apparently minor change resulted in a drastic drop in spam for us.

One suggestion to really force the no-autocompletion :
change autocomplete="off" by autocomplete="nope" OR autocomplete="false"
Since the given value is not a valid one (values for autocomplete are only on or off), the browser will stop trying to fill the field.
For more details, How to Turn Off Form Autocompletion.
Hope this helps.
SYA :)

If you are using Ruby on Rails, you can try invisible_captcha gem. A solution based on this honeypot technique.
It works pretty well! At least for small/medium sites... I'm using it in production, for years, in several Rails apps with very good results (we hardly receive spam since its implementation in "contact" forms, sign-up, etc).
It also provides some extras (already listed in https://stackoverflow.com/a/36227377/3033649):
time-sensitive submissions
IP based spinner validation
Basic usage
In your form:
<%= form_for(#user) %>
<%= invisible_captcha %>
...
<% end %>
In your controller:
class UsersController < ApplicationController
invisible_captcha only: [:create]
...
end
And you're done! Hope it helps!

Related

Can I use HTML to create a vote button on an email that sends a reply?

Situation:
I am a HTML newbie who gets by through Google-fu and I am in charge of a tool which sends HTML email to customers.
I have been asked by our customers (Because pressing reply and typing a single word is really difficult) if I can create buttons on the emails I send which allows them a 1-click reply.
Conditions:
The reply has to come from their own email address
It needs to go back to the email address that sent the email (We have one template email which can be sent from several addresses)
It needs to maintain the same subject line (It contains a reference number to ensure the email is processed correctly when received)
Must be created using inline HTML(4 or 5) only (Restrictions of the system that generates the email)
Ideally will send the reply immediately (And show them as much in some manner), but opening up a new email already pre-populated is an acceptable alternative
I have struggled to find much at all on this, which leads me to think that it is not possible.
If using tiny bit of pure javascript, that does not need any external library on your website.
This code goes to your website where you want your check to be made.
<script>
function getURLParameter(name) {
return decodeURIComponent((new RegExp('[?|&]' + name + '=' + '([^&;]+?)(&|#|;|$)').exec(location.search) || [null, ''])[1].replace(/\+/g, '%20')) || null;
}
document.addEventListener("DOMContentLoaded", function(event) {
if(getURLParameter('answ') == 0) document.getElementById('answered_yes').remove();
else if(getURLParameter('answ') == 1) document.getElementById('answered_no').remove();
else {
document.getElementById('answered_yes').remove(); document.getElementById('answered_no').remove();
}
});
</script>
<div id="answered_yes">
THIS IS HOLDER FOR YES ANSWERER //Put your wanted info hare if he answered yes
</div>
<div id="answered_no">
THIS IS HOLDER FOR NO ANSWERER //Put your wanted info hare if he answered no
</div>
Now on email links put these type of links.
<a href="yourwebsite.com/index.php?answ=0" target="_blank" >ANSWER NO</a>
<a href="yourwebsite.com/index.php?answ=1" target="_blank" >ANSWER YES</a>
What this does is simply puts a parameter on a link called answ that has 0 or 1 by my setting and once your website gets a request it checks which parameter is it 0 or 1. If its 0 that means we remove the div that says yes, otherwise do the same with no div.
with only html it is not possible unless you would give him different links as in.
<a href="yoursite.com/he_answered_no.html" >No</a>
<a href="yoursite.com/he_answered_yes.html" >Yes</a>
And put your contents inside there.
However if you are going to use this script in your website, put that code somewhere in the body, its not perfect, but it will do the job. Then put your information on yes div and on no div, its going to remove whatever div he answers too.
But like I mentioned, with purely HTML it is not possible only adding some bits with other languages, pure javascript should work on any HTML site, unless you are trying to add the code to some kind of platform that blocks any ongoing scripts.
You can just use a "mailto:" link similar to this:
Email Us
Here's the link with more info: https://css-tricks.com/snippets/html/mailto-links/
It will open up a prepopulated email with the "to" address, subject line, and body text already inserted. People will be able to modify the text if they want or just click send. You would need to some way to dynamically change the subject line to the one the customer received, but your email tool probably has that capability.

PHP form handler-using "required" instead "isset" when not filled

Is it good to use "required" in input like this:
Name:<input type="text" name="name" required>
Or should I remove it and use "isset" in PHP? If I understand properly, both show you error, when you want to proceed next without filling input's, but required just awares you, while isset throw's you mostly to new page and reset the form(not good if you only forgot to fill one input).
Or should I remove it and use "isset" in PHP?
Why do you feel the two are mutually exclusive? Use both.
The required HTML attribute provides a smoother client-side user experience. It allows some basic validation without having to re-engage the server. It does not, however, do anything to validate incoming requests in server-side code. isset (among lots of other potential logic) can and should be used server-side to do just that.
Use client-side validation logic to present users with a better user experience. Use server-side validation logic to actually validate the user input before conducting business logic. Validation can live in lots of places for lots of reasons.

Google Chrome Inspect Element Issue With Hidden ID's

I am not 100% sure if this is as big an issue has I seem to think it is right now but I think I may of found an issue or at else an hole within the Inspect Element viewer within Chrome.
I was using (I have now changed my settings) hidden ID's to set a number of defaults, one was users levels, another was to make the user active by default.
However when I view these ID's within the inspect Element view and then changed the values, submitting the form would submit the NEW value to the server and not the value I had given it.
For Example:
I had something like the following within my code,
<input type="hidden" name="data[user][level][id]" value="1" id="MyID">
I then changed it within the Inspect view to,
<input type="hidden" name="data[user][level][id]" value="2" id="MyID">
Then I submitted the form and was surprised that the NEW value was submitted, I was always under the inpresion that hidden ID's where not changeable and the browser should only submit the default values held within.
I have now changed this to letting the database default to a basic user and then I can change the users setting has I want to. But in some cases this may not be an option, so I was hoping for an answer or some feedback about how to make this more safe.
Am I just a bit slow, are there better methods (different ones) to passing 'hidden' data from forms to the server?
I was thinking about maybe using JQuery to add the needed hidden fields to the forms once the user had selected / submitted the form, but i am not sure if this is 100% safe or even if its a good idea.
Any ideas / feedback are very welcome.....
Many Thanks,
Glenn.
I had the same problem passing the database data into a modal,the solution i know is to use jquery ajax to get the informations from the database requesting a file,adding them into variables and compare the variables
$.ajax({
url: "test.html",
context: document.body
}).done(function() {
$(this).addClass("done");
});
I used this code sample to do it.
Of course there are a few modifications to be done depending on your script
I found a better way of doing this, at lest in CakePHP. The CakePHP framework has inbuilt security calls. These in-built functions when added give you all sorts of stuff but the main reason I used them was to stop this sort of form tampering.
I am not 100% sure how it does this, but it adds a token to all forms and it checks to see if the form being submitted is right? Again not sure how the token works.
But here is the code I used ::
public function beforeFilter() {
$this->Auth->allow('index', 'SystemAccess');
$this->Security->blackHoleCallback = 'blackhole';
}
public function blackhole($type) {
$this->Auth->logout();
$this->Session->setFlash('Sorry a security issue has been detected, please try again or contact us for support.', 'default', array(), 'bad');
$this->redirect($this->Auth->redirect('/'));
}
Now I will add that the call the Auth logout I added to this for extra added security, as the user maybe have logged in on a system and it just not be them that is trying to do things that they should not.
Hope that helps others out!
But this is only a fix for when CakePHP is in use. I would take it that other frameworks would have their options but if your only using basic HTML? or a CMS like Drupal again there might be in built security.
Many Thanks
Glenn.
The only safe and best solution that I found for this issue is to check on the server side whether the user_id sent with the form is the same user_id logged in with or not.
Although using jquery is good idea, but, did not work with my case as am using data: $(this).serialize(),
However here's my code on the server side (Note, am using Laravel 5.4, but am sure it won't matter with your case)
if ($request->user_id != Auth::user()->id)
return json_encode("F**K YOU ! Don't Play Smart -_- !");
else
raw_material_category::create($request->all());
Hope this helped ;)

ColdFusion - Sending out a pretty email, mint style

I've used ColdFusion for sending text emails for years. I'm now interested in learning how to send those pretty emails you see from companies like Mint.
Anyone know of a good ColdFusion tutorial to teach me how to make this work and not get hit by bugs or spam filters?
As Ray said, ColdFusion supports HTML email, which is how you make an email "pretty". A quick down and dirty sample looks like this:
<cfmail from="bob#bob.com" to="someguy#email.com" subject="Check this out!" type="HTML">
<HTML>
<head><title>My Email</title>
</head>
<body>
<!--- Style Tag in the Body, not Head, for Email --->
<style type="text/css">
body { font-size: 14px; }
</style>
This is the text of my email.
</body>
</HTML>
</cfmail>
That's it, you've just sent an email. Notice how there is nothing preventing you from sticking in any old from email address you like? That leads me to my next point, in which you're wondering how to avoid getting hit by Spam filters:
The short answer is: You can't.
Oh sure, you can do intelligent things, like not including the word "VIAGRA" in your email (unless you're trying to send out penile enlargement emails and want to know how to get past spam filters, in which case I'm disinclined to help), but let's assume you just want to avoid obvious pitfalls.
I can think of two things that might help:
Send out email from a domain registered to the from email address. I didn't make the rules, but this one can be a pain. Ie., If you try to send out proxy emails for myorg.com, and your server does not host myorg.com, some spam filters are going to block it. What is usually done is to apply some branding to the from email, like this:
<cfmail from="MyOrg.Com <DONOTREPLY#registeredsite.com>" replyto="bob#myorg.com" to="someguy#email.com" subject="Test" type="HTML">
</cfmail>
In this case the email is sent from your server at registeredsite.com, with a replyto being the proxy email address. Spam filters will probably be okay with this, since the from email address of *#registeredsite.com resolves to your server. Try to send out with bob#myorg.com in the from, and you'll definitely run into some places that will block you.
Use a physical server, not a cloud site. I'm running into this very issue right now, but if you don't use a physical server that is located at a dedicated IP to send out your email, and if this server is not the originator of the email, some places are going to block it. This means no EC2 or Rackspace cloud site--sorry, some sysadmins are inclined to put down the banhammer on anything that originates from one of these providers, seeing as it is so easy to churn up your own little spam factory using EC2 or Rackspace for very little cost.
Even if you take these precautions, however, you'll run into a situation where someone gets a hold of your domain name and drags it through the mud. They'll send out thousands of emails to the internet in your name--or rather, in your domain's name--and because of the insecurity of email, your domain will get added to someone's blacklist after a thousand occurrences of hotlove4u#registeredsite.com hit the sysadmin's inbox. There's nothing you can do about it, either.
Or you can decide to run a cloud app and use a remote mail server. But some jokers will get one look at the originator being EC2 and will say, "Nope, sorry. Denied." They don't care about the legitimacy of your organization, only the origin of the email.
Email is an antiquated technology that has been rushed into mass usage before we really were able to think of a better protocol. As a protocol, it's terrible....and yet we're stuck with it, for backwards compatibility reasons. You cannot possibly avoid the spam filter. 95% of the email on the internet is junk mail, and never even reaches the intended recipient. Just absorb the enormity of that statistic for a moment, and pull your ideas back to reality. Many of the spam-prevention techniques being used today are unnecessarily aggressive, and create a great many 'false positives'. You can shoot for, say 80% of your email being sent, but what it really comes down to is this: As soon as the email has been fired off, it's completely out of your control. You can only take responsibility for so much.
What do you mean by "pretty" - HTML based? CF supports html email. Just use type="html". You can also use cfmailpart to send both text and html versions of the same content.
Here's a good article on making HTML email using CSS:
http://articles.sitepoint.com/article/code-html-email-newsletters
Ray's answer is right on the money about the CF part, but most of making this work is about HTML, CSS and testing testing testing.
And I would add to this all that you can check whether a mail will be displayed correctly and whether it will get hit by a spamfilter or not by going to a website that is called litmusapp. You can send your test newsletter to one of their emailaddresses and then they will give you screenshots of how each newsletter will look like in each type of emailclient. Also it checks the newsletter against a few popular spamblockers and gives you advice on what to change.
I would start by finding an HTML template email that you like. Then you put it in the tags with the type set to html as mentioned above. You might want to consider doing the multipart email to handle plaintext (and blackberry) users.
I subscribe to the Campaign Monitor Newsletter & they also have a list of very useful articles here: http://www.campaignmonitor.com/resources/
Might want to check out this ebook from MailChimp. Email apps render HTML in some unusual ways, so be prepared to use tables for layout.
Remember when you try to change the color of the font or background when you writing a cfmail, before you add #F0000, you need to ad extra # at the front of it, like ##F0000. Otherwise, it will cause an error.

Implementing "Report this content" and detecting spammer or robot triggered event

I'm creating a forum for a website, and plan on implementing a "Report this content" function.
In all honesty, I'm not sure how useful (lit. necessary) the feature will be, since a user account (created by admin) will be required for posting, but the solution interests me.
So in short, this is the scenario:
For all users, there will be read-only access to all (non-restricted) content on the forum. For unidentified users there will be a reply button and report this content button present. The former will proceed to require a login, while I had planned that the latter wouldn't, so that anyone would be able to flag suspicious or offensive content.
The problem I'm thus facing is basically "robot clicks", or rather how to implement the system so it won't be fooled by "robot clicks".
There are a few methods that come to mind:
1) User-agent
2) Requiring several flags (in a predefined timespan?) before reacting in any way
3) robots.txt
4) Requiring human input on a second form (captcha or "specify reason")
What I think of them:
1) Unreliable (as sole solution)
2) This requires a mass of users which might lead to the event never being triggered
3) This is probably the "right" way to go, but will only work for those who respect it
4) Meh, I hate captcha and requiring a reason might raise the bar too high to keep the function useful
What methods would the (highly enlightened) community have to share with me?
You could append the 'report this' <form> to the DOM with javascript's appendChild();.
This would prevent a lot of spam.
It would also prevent users not running javascript from seeing the report button. But since this is a feature that does not hinder the user-experience, it is probably an acceptable option.
window.onload = function() {
var f = document.createElement('FORM');
f.method = 'post';
f.action = 'report.cgi';
var b = document.createElement('INPUT');
b.type = 'submit';
b.value = 'Report this';
f.appendChild(b);
document.body.appendChild(f);
}
Note:
The rel="nofollow" attribute makes sure search engines do not 'count' the link, they do however follow it (yes, the name suggests differently).
If you want the search engines not to touch a certain file, use robots.txt
Note 2:
Reporting something is an action that 'changes' something on the server. Thus, it should not be a GET request Instead it should be a POST request. In other words: do not use a <a href""> but instead submit a <form> with its method argument set to "post".
You could simply redirect to a form where the user needs to enter a reason for reporting the content. A robot probably would not enter anything here and the form would not be processed if the user didn't enter anything.
You missed making the link a nofollow one, but I'd opt for a combination of requiring human input (reason, details of complainant) to counter robots and requiring a number of flags to stop people just flagging people they disagree with/don't like on the forum.