Bug #89420

Make honeypot in ext:forms more reliable

Added by Christian Eßl over 1 year ago. Updated 12 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Form Framework
Start date:
2019-10-15
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:
Remote Sprint

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.


Related issues

Related to TYPO3 Core - Bug #91435: The 'form' Honeypot partial inserts invalid HTMLNew2020-05-19

Actions
#1

Updated by Gerrit Code Review over 1 year 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

#2

Updated by Susanne Moog over 1 year ago

  • Sprint Focus set to Remote Sprint
#3

Updated by Gerrit Code Review over 1 year 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

#4

Updated by Gerrit Code Review over 1 year 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

#5

Updated by Gerrit Code Review over 1 year 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

#6

Updated by Gerrit Code Review over 1 year 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

#7

Updated by Gerrit Code Review over 1 year 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

#8

Updated by Christian Eßl over 1 year ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#9

Updated by Gerrit Code Review over 1 year 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

#10

Updated by Christian Eßl over 1 year ago

  • Status changed from Under Review to Resolved
#11

Updated by Benni Mack over 1 year ago

  • Status changed from Resolved to Closed
#12

Updated by Andreas Lochner over 1 year ago

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

#13

Updated by Bjoern Jacob over 1 year 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.

#14

Updated by Dmitry Dulepov over 1 year 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.

#15

Updated by Wolfgang Klinger about 1 year ago

  • Related to Bug #91435: The 'form' Honeypot partial inserts invalid HTML added
#16

Updated by Ralf Zimmermann 12 months 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).

Also available in: Atom PDF