TYPO3 Core

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

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

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

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

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

Problem still exists. If you click the submit button a second time you bypass the honeypot.

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.

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.

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).

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”.