As you may know, Chrome does not support:autocomplete="off", autocomplete="nope", autocomplete="false" or even autocomplete="new-password" any longer.
That means, from time to time, I do get reports that honeypot traps are preventing users from submitting forms, since the trap input is being auto-filled, even if not shown.
The practice for setting the trap is wrapping a TEXT input with a display:none; element, so spam bots won't be able to figure its really hidden (unless they are smarter and they usually aren't), and if this input has contents, you won't allow the submission to go through, as the field supposed to be hidden and empty for regular users.
What's your practice in using honeypot traps while still having browsers ignoring the demand for auto-complete or auto-fill by using the above arributes?
My current solution (October 2022) for a honeypot field looks like this:
Move the input field out of the visible area using css
Avoid name attributes that Chrome looks for when autofilling, like email, address, etc.
Do not wrap the honeypot input element with other elements that contain such keywords in their label or in name attribute
If you are using FormFind (which analyzes a page's source code and extracts the 'action' parameter and the input tags will find hidden fields. Hidden fields will not stop a spambot.
FormFind will find all the fields on a form from the HTML source code. And once you find the input fields - and the 'action' parameter (which FormFind does find) - its easy to use CURL or WGET to 'submit' the form.
Although reCAPTCHA will help with spambots, the only technique that I have found (and what I use in my solution) is to have some JavaScript code that will change the form's action parameter on a onclick/onfocus event. And if you put a delay in the JS function that changes the action parameter, that's a bonus spambot blocker.
Using JS to change things (or even to fill in a hidden field, if you insist on using one) is a good technique. CUSL and WGET cannot process JS code. (There was an open source project that claimed to be able to process JS code, but it was abandoned a couple of years ago.)
The JS trick is what I use in my contact form at my free FormSpammerTrap.com site. Code is free and open source. And the contact form there uses my technique. Have not gotten any spam via a spambot (automated process) from there. And I am working on a newer version that will add delays to even further block spammers.
Anyone is welcome to request the code to try it out. No charge. No fees. No advertising. No $$ benefit to me, other than how I use it on my sites to block spam.
So, using hidden fields to stop spambots is not going to work well. You have to have more layers of defense against them. Using JS code techniques is another layer that will help block almost all spambots. (There's no 100% solution, but I think mine is close - and it's been around for a couple of years.)
I removed the name variable from the input tag and this resolved the issue of the hidden honey pot fields getting autofilled...
Related
Problem Background & Steps
I am using Chrome 58 on a Mac OS version 10.12.3.
Something like this is happening: StackOverflow - What is _lpchecked=“1” for in a form?
This attribute is added to the parent form element when I click inside of a child input element.
My problem is that when this happens, the attribute "autocomplete=off" is added to the input element.
When switching between child input elements, this attribute is added to the currently focused element.
The element names are "to_email" and "comments".
This is not a login form, but a sharing form.
This seems to happen based on me having the LastPass extension, the name of the variable, and a bit of online searching.
I have tried going into the LastPass Account Settings area, "Never URLs" section/tab, and adding the URL to the "Never Do Anything" category.
The URL is of the form sub.domain.tld/path/resource.php?queryParam=value. LastPass would only allow me to add the URL without the query portion to the list, even when I tried a wildcard asterisk (*) for the value.
Even after accessing the LastPass Extension Menu > More Options > Advanced > Refresh Sites, Clear Local Cache, and refreshing the page, this problem still occurs.
I did not see any information in the Hacker News article about a similar signon.overrideAutocomplete property in Chrome like Firefox has, and may not want such a broad solution anyway.
I don't want to have to install another extension like autocomplete-on
(seems to not exist) and have functions 'battle' each other, which may not even produce desirable results, like working at all, or flipping constantly.
I have even searched for what else might be doing this with words such as "adding attribute" and "dynamic", but Google biases the results to less complex scenarios about specific pages, something I could try to solve with TamperMonkey if I wanted to.
If there was any such problem like 'sniffing' for more autocomplete information, as somewhat mentioned by these links:
yoast - Why you should not use autocomplete
Alex Maccaw - Chrome’s requestAutocomplete()
Then hopefully it should be fine if I only fix this problem on a limited basis, especially only for forms with insensitive data.
Questions
How can I prevent LastPass from adding this attribute?
Is it just LastPass doing this?
Have I entered the URL correctly to "Never Do Anything"?
Funny Link
Hacker News - The war against autocomplete=off (2013)
For now it seems to work if I add a TamperMonkey script to overwrite the value.
This is not as large a solution as the jonmetz fellow mentioned making his own plugin (his is in Firefox), and can be duplicated as needed. If this is needed a lot, then maybe an extension would be more convenient.
Because of the dynamic and repeated nature of the issue on the page, a simple assignment did not work, and was overwritten.
My preference for the attribute remains as the end result if I add an onFocus Event Listener thusly:
var emailInput = document.querySelector('input[name="to_email"]');
emailInput.addEventListener('focus', function(){
this.autocomplete = "on";
});
I also do this in case it helps at all:
var parentForm = emailInput.parentNode;
parentForm.setAttribute('_lpchecked', '1');
So basically, the website is javascript free. No javascript at all. Will not be adding javascript.
However, we need to prompt the end user to enter information accordingly to be used in a database that will then connect to software on the network.
As in, there are 2 hyphens preinserted into a form field for a telephone number. This will prompt the user to enter 310-555-5555 instead of 3105555555.
*** I am a translator for a website owner and a web developer. I am not a programmer. I need a simple answer. I dont need you to explain how to do it. I just need to find out if the programmer is capable or if the website owner is asking for something impossible.
Yeah, it is absolutely possible. There are HTML placeholder attributes available which will do your job.
For modern browsers the HTML attribute placeholder already exists and does exactly what you mentioned.
http://caniuse.com/#feat=input-placeholder Browser support is pretty strong nowadays
Side notes that may not be needed after you further clarified you wouldn't be doing the work:
With that said it gets a little bit more involved if you want to have all users get that information and see it (this is in regards to accessibility). Also placeholders disappear after a user starts typing. Not sure if that is an issue.
Having the explanation part of the label as well (styled differently) will make it always visible and readable by different user interaction.
You can use placeholder attribute to prompt the user to insert a specific format and pattern attribute to validate the pattern entered.
<form>
<input type="text" pattern="\d{3}[- ]?\d{3}[- ]?\d{4}" placeholder="XXX-XXX-XXXX">
<input type="submit">
</form>
I have a form with a read only field for display/submit to the next page purposes.
However, I noticed using developer tools in Chrome, I was able to add an id to an element, use the javascript console to select that element, and change its value. I submitted the form and what do you know - the next page acted on it as if it was the original value.
Now, there shouldn't be any problem with the people using the site I'm building, but it seems like a huge security flaw to me. Isn't the point of read-only to remain constant? If a savvy user to change it around, doesn't that pose a big problem? In fact, I didn't even think you could add and change attributes in chrome.
Please post your thoughts below, and let me know if there's a solution ("disabled" textfield, but setting the disabled property doesn't send the data to the next page).
NEVER trust input from a web form.
The user could, just as easily, remove the readonly attribute and edit the value. The readonly attribute is only something to help the user when filling out the form, so they don't edit a value expecting it to change, when your server actually won't let it be changed. So, always remember to code the behavior on your server first, and have the HTML form be a helpful guide for users to make the form easier to fill out (without having to submit the form several times to get relevant error messages).
To overcome this, if something is readonly and you do not want it edited, you could store the value in your database. Also, values provided by users should always be checked (and sanitized) as no amount of JavaScript, HTML, or CSS is going to prevent someone who knows what they're doing from adding new or changing/removing existing values.
Input fields are usually associated to forms, but I would like to use them in a simple Javascript/HTML page. I don't need the form. I see no issue with my HTML page, but is there any danger or bad practice I am not aware of? I just don't want my page to bug down the road.
(Basically, a field in my page can be Javascript enabled or disabled according to values in other fields)
The only real problem is if you want your page to function for users who have JavaScript disabled - if the inputs are actually for user input then placing them outside a form means that you'd need to use JavaScript (presumably with Ajax) to do anything with the values, whereas form fields can be submitted without JavaScript. If your page isn't intended to be submitted to the server anyway then you're dependent on JavaScript for interaction. If you've taken that into account and it doesn't matter for your scenario then go ahead.
P.S. I should've mentioned that as far as HTML standards go it is perfectly valid to have input elements that aren't in forms.
You should be fine AFAIK. It's ok in the HTML 4.01 standards anyway
http://www.w3.org/TR/html401/interact/forms.html#form-controls
The elements used to create controls generally appear inside a FORM
element, but may also appear outside of a FORM element declaration
when they are used to build user interfaces. This is discussed in the
section on intrinsic events. Note that controls outside a form cannot
be successful controls.
You can use an HTML validator (here, or on many other sites) to check this sort of thing. If it shows up legal, which I think it should in this case, as Ted pointed out, then you are probably good.
I'm trying to reduce the form spam on our website. (It's actually pretty recent).
I seem to remember reading somewhere that the spammers aren't executing the Javascript on the site.
Is that true?
And if so, then could you simply check for javascript being disabled and then figure it's likely that it's spam?
There are still a large number of people that run with Javascript turned off.
Alternatively, I have had decent success with stopping form spam using CSS. Basically, include an input field and label that is hidden using CSS (display: none;) and once submitted, check if anything has been entered in the field.
I generally label the field as a spam filter with an instruction to not put anything in the field, but all newer browsers will properly hide the block.
More: Fighting Spam with CSS
reCAPTCHA is also surprisingly easy to implement.
check http://kahi.cz/wordpress/ravens-antispam-plugin/ for a nice answer
if puts in
<noscript><p><label for="websiteurl99f">Please type "e73053": </label><input type="text" name="websiteurl99f" id="websiteurl99f" /></p></noscript>
<script type="text/javascript">/* <![CDATA[ */ document.write('<div><input type="hidden" name="websiteurl99f" value="e' + '73053" \/><\/div>'); /* ]]> */</script>
so javascript users see nothing, non js users just type in a word
if a spammer targets you specifically it won't take them long to code round it but for drive by spammers it should be good
In the same vein, adding a dummy field and then using CSS to hide it is a good way to trick the bots. If the field is submitted, you know a non-human probably completed the form.
Especially effective if you label/name the field something along the lines of URL or website.
You could check - have JavaScript that populates a hidden form field with a specific value after the page loads. Then, when the page posts back to the server, check that hidden form field the expected value. If it is not there, that means the JavaScript didn't execute.
As to whether you should assume it is spam is another story altogether, and one that has no certain answer, really. You could simply have a <noscript> tag and have it indicate to the user that their submission will not take unless they enable JavaScript.
Once you have JavaScript running, however, the spammers will just use another workaround for that. :)
I can't remember where I've seen this method but spam bots like to fill out forms. Have you considered putting a form field that is hidden with javascript (and says don't fill this field if the user doesn't have JavaScript). This way if something fills in this field you can ignore it as spam.
Did you have any luck with this? I think some text based browsers have implemented basic JavaScript support, so maybe spam bots have as well?
Otherwise I'm considering using a captcha for users without JavaScript and some automatic JavaScript check for other users.