Bug #89420
closed
Make honeypot in ext:forms more reliable
100%
Description
We encountered problems with the honeypot in ext:form, that a lot of spam messages still come through.
The way the honeypot currently works is, that a random, visually hidden, input element is inserted into every form by default.
If the hidden input has a value, the user will be automatically redirected to the form (instead of calling the finishers).
In that case, all values that were previously present in the form, will be refilled again, except the honeypot field (which now has a different id).
This means, if the bot now just resubmits the form after the first failed attempt, without changing any of the values, the form will now successfully be submitted.
I will provide a patch later, that refills the honeypot field on a successful bot detection. At least in our tests in the wild, this has significantly reduced the spam messages.
Updated by Gerrit Code Review about 5 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62000
Updated by
Updated by Gerrit Code Review almost 5 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62000
Updated by Gerrit Code Review almost 5 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62000
Updated by Gerrit Code Review almost 5 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62000
Updated by Gerrit Code Review almost 5 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62000
Updated by Gerrit Code Review almost 5 years ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62000
Updated by Christian Eßl almost 5 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset af043ee31b7c9fccb12dceb8a3625a9d0f5c9d24.
Updated by Gerrit Code Review almost 5 years ago
- Status changed from Resolved to Under Review
Patch set 1 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62376
Updated by Christian Eßl almost 5 years ago
- Status changed from Under Review to Resolved
Applied in changeset 33a011f51644851047d4a159f6f6dad1d3c7810c.
Updated by Benni Mack almost 5 years ago
- Status changed from Resolved to Closed
Updated by Andreas Lochner almost 5 years ago
Problem still exists. If you click the submit button a second time you bypass the honeypot.
Updated by Björn Jacob almost 5 years ago
Thank your Andreas for your feedback. Please do not re-open issues :)
Unfortunately, the days of honeypots are over. The solution is not reliable anymore. The autofill functionality of Chrome/ Chromium is enormous and ATM kind of quirky. Do you have the possibility to use powerful tools like Spam Assassin on your mail server? We definitely recommend this in favor of the honeypot solution. It would be great to learn about your ideas to improve the current situation.
Updated by Dmitry Dulepov almost 5 years ago
The solution seems to be wrong completely because the only thing it does is: it sets the autocomplete attribute to invalid value ('off' or 'on' is allowed, nothing else). So I do not see how this may work and I do not understand how this got approved. "The fix" creates invalid html on the page.
Updated by Wolfgang Klinger over 4 years ago
- Related to Bug #91435: The 'form' Honeypot partial inserts invalid HTML added
Updated by Ralf Zimmermann over 4 years ago
Dmitry Dulepov wrote:
The solution seems to be wrong completely because the only thing it does is: it sets the autocomplete attribute to invalid value ('off' or 'on' is allowed, nothing else). So I do not see how this may work and I do not understand how this got approved. "The fix" creates invalid html on the page.
If the name of the honeypot field contains some chars which matches the Browsers autofill regex pattern (https://github.com/chromium/chromium/blob/5010349367c9d74bf5946273c1ead4a29e61d18c/components/autofill/core/common/autofill_regex_constants.cc#L89), then the autofill is happened (as described here https://review.typo3.org/c/Packages/TYPO3.CMS/+/62000/7#message-a804d62b94d103b35774219a086dafee47eb0341)
My unerstanding of
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill-detail-tokens
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete#Values
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#Preventing_autofilling_with_autocompletenew-password
was that we can use "autofill detail tokens" as values for autocomplete attributes and if the "autofill detail token" does not match one of the implemented tokens, the autofill will not happened.
So the strategy was to use an autofill detail token, which most likely will not be implemented by the browsers (the honeypot element identifier).
Updated by Jo Hasenau 9 months ago
The actual validation problem is, that the field is hidden AND got an autocomplete value - it does not matter if that value should be "on" or "off", since any other given value than "off" will be treated as "on" anyway. The actual broken validation rule is:
An “input” element with a “type” attribute whose value is “hidden” must not have an “autocomplete” attribute whose value is “on” or “off”.
Updated by Oliver Hader 23 days ago
- Related to Bug #103776: Make honeypot fields of EXT:form w3c valid added