No longer protecting

We are also seeing this, specifically in the last few days and on all of our clients sites. Antibot is no longer stopping spam submissions on webforms and on a couple of sites where visitor registration is possiblle it is also no longer preventing spam sign ups.

Antibot has always worked fine for us up until the last few days, however I have no evidence to prove that it just hasnt been subjected to severe spam attacks up until now.

On one site which has both Antibot and Honeypot installed (with time restrictions enabled) we are suddenly seeing large amounts of spam through a webform, the only way we were able to stop it was to enforce telephone number validation on the form.

It feels to me like more advanced bots have appeared in the last few days which have made made Antibot and Honeypot no longer effective.

Confirming I'm seeing the same thing since the last few days. It seems there's a new spambot in town.

Same here on several sites.

Same here. Registrations, Webforms etc are defeated regularly.

I also tried adding the Honeypot module ( https://www.drupal.org/project/honeypot → ) into the mix, but that didn't make much of a difference. I really hate captcha modules, so I hope we can find out how they do it and come up with a solution.

I got the same issue. I have just patched the antibot module on one of my sites, so it will log the events which triggers the unlock function. Hopefully it will tell us something useful.

Same issue here, using the 7.x-1.2 version.

Some more details that might be useful:
- my forms are not visible on a dedicated link (only added to a page through a reference field)
- most sites are running the latest version of Drupal, Antibot and Webform (although the problem occurred on a D9 site as well)
- all sites have recent versions of PHP/MySQL

More details: both comment forms and Webforms are bypassed. Also most updated version of D10.

Same here. Honeypot doesn't help

Hmm, it looks like the spambots aren't triggering any of the events that should unlock the webform, or they aren't submitting the hidden field which contains the logged events.

When going to Administration > Configuration > User Interface > Antibot Settings to configure Antibot, I am seeing:

Status message
Antibot (antibot_settings): disabled

Would this be contributing to the huge increase spam in the past 1 to 2 weeks? If so, how is it re-enabled? Thanks!

I did some more research and now I'm sure the hidden fields are submitted, but no event was logged. Even the initial attach method isn't called, implying that the bot is not loading and/or executing JavaScript.

I saw that the antbot_key is stored in the drupalSettings and is readable in the markup even without JavaScript. A possible solution is that the antibot key must be "transformed" server-side before attaching it to drupalSettings and to use JavaScript on the client-side to undo the "transformation" when the unlock function is called.

Maybe I can look into this later today.

This patch will do some shuffling logic on the antibot key which is needed to submit the form. Which means that the real antibot key is not in the drupalSettings anymore. Only a shuffled version of it is in the drupalSettings. The unlock method in the antibot.js file (which is responsible for adding the key) is now also "unshuffling" the antibot key to the real one before adding it to the form.

I'm not sure if this is preventing the bot from filling in the form, so please share you findings.

Thanks for your work Ewout! I've applied your patch to 2 live sites, I'll gather the results and I will share my findings.

Same problem here, large amounts of new user registration on an up-to-date D10. Spam mail-adresses are mostly in the form of e.g.

'iha.veno.cl.ueh.ow.tost.opthis@gmail.com'

with a lot of dots in name. I am now trying the patch in #14.

Thanks @jurveen and @Volker23 for testing. Hopefully the spam will stop with this patch.

Thank you for your quick reaction Ewout! I'am also testing the patch (on a d9.5.9).

Patch applied to one of the websites where I receive spam through the contact form. I have other websites where spam also arrives daily, but I have not applied it there to check if the spam stops because of the patch or because the bot has given up. In a couple of days, I will inform you if the patch has worked or not.

@Ewout Goosman, half a day without spam, this looks very promising. Thanks!

The same here.
The website where I applied the patch has stopped receiving spam, the rest of the websites without the patch continue to receive spam.
If it continues to work well tomorrow, I'm going to apply it to all my websites.

Would somebody please be willing to convert the patch to the 7.x-1.2 version?
I tried to do this myself, but unfortunately am unable to get it working.

I applied the patch #14 with no issues, tested this on a DEV site exposed to the internet and haven't got any spam for now (again, it is a dev site so it isn't getting a lot of requests).

Please let me know how this is working on your end (not getting spam after applying the patch) and I'll commit this to the 2.0.x branch.

I'll try to create a patch for the 7.x-1.x version.

I have applied the patch to 4 websites.
To the website that was receiving the most spam, I applied the patch 2 days ago.
Seeing how well it works, yesterday I also applied it to 3 websites that have been receiving little spam for about 2 weeks (at least 1 email at night and 1 email during the day).

Since yesterday, I have not received any spam.
I believe the patch can be included in branch 2.0.x.
In case I receive spam again, I will notify you here, but the patch is very promising.

Thanks for the patch

We are using Antibot on more than 20 installations. Antibot was doing really well in protecting against spambots for several years, in a 'set it and forget it' way. Beginning of last week, we started receiving messages from several clients saying spam was getting through the webforms, mostly simple contact webforms.

At first, I thought these spam messages were human spam. But the amount of spam was increasing and the IP addresses are rather random, which points to spambots bypassing the Antibot protection. Most spam I've seen was maximum five/six messages per day: no huge numbers but still annoying.

I've added Honeypot (with a non-default hidden field name) to some Antibot instances but that didn't help. Honeypot used to be an elegant anti-spam method but it doesn't work anymore for us. This week, I've been busy implementing reCAPTCHA 3 (with the Simple Google reCAPTCHA module) on several instances. This blocks the spam but creates another dependency on Google.

I will try patch #14 on the remaining instances.

I also applied the patch to 4 sites two days ago, and the spam was all blocked.
Everything seems to be working perfectly.

Thanks for the patch.

I've applied patch #14 to 6 websites that I maintain.
Before the patch, some sites received up to 10 spam messages per day via the webform contact form.
Now, 2 days with the patch applied: no spam at all.

Thanks again @Ewout Goosman for your work!
As @trebormc suggested, I think too that this patch should be included in the 2.0 branch.

We can also confirm that this patch fixes the spam. We've applied it to 10 sites on Friday, and none received any spam over the weekend. We didn't see any other negative impact on legitimate form submissions, etc.

It would be great to have a new release with this patch as this is highly critical.

Seeing that multiple people confirmed this I'm marking this issue as RTBC.

I'll add my 2 cents: Installed on two sites on friday (the ones with the most spam). They received no more spam since then. The other sites that run antibot still received a lot of spam. Also legitimate submissions still arrived (test and real-world).

Same here. no spam received since patch applied on 2 websites and the legit emails are still coming.

The patch also works fine on my sites. I installed it on one page with > 1000 spams per day - and the spams have gone while wanted webform submissions still arrive.

By the way: I am also interested in a Drupal 7 compatible patch. Is someone already working on this?

Thank you Ewout. Patch applies for me.

I saw that the antbot_key is stored in the drupalSettings and is readable in the markup even without JavaScript.

Has this always been the case? Good spot and fix.

Thanks everyone for the feedback, I just committed the patch to the 2.0.x branch, I'll release a tag version shortly.

I'll work towards creating a similar patch to the 7.x-1.x branch.

Created a new release with this patch: https://www.drupal.org/project/antibot/releases/2.0.3 →

Thanks a lot to everyone involved, and let me know if there are still issues with this.

Moving this to "Fixed" for now.

Good to hear that the patch is working fine and that it's included in the latest release :)

A couple of users have reported getting a "Submission failed. Please reload the page, ensure JavaScript is enabled and try again" error. I have confirmed that javascript is on for them. Is there any error in the key scrambling or other logic that was introduced in the patch?

edit: I have now tested myself on one site and also get that message when filling out any form that is protected (login/webform). I have javascript on and tested incognito without any extensions.

I tried both the patch and the updated module.

Can you ensure that your JavaScript cache has been cleared? If you inspect the source, you should be able to find the following line:

input.value = config.key.split("").reverse().join("").match(/.{1,2}/g).map((value) => value.split("").reverse().join("")).join("");

If you can't find that line, search for

input.value = config.key;

If you can find that one, it means that you are still using the old JavaScript.

I did clear cache a couple of times. But i guess the update didn't go well. I should've suspected as much since this was the only site with a problem.

The update is working well on our side. Thanks!

@Dries Arnolds
Just trying to shed some light on your problem.
Does that website you're having trouble with have js file compression enabled? If not, you're just clearing Drupal's caches, but not forcing the user's browser to download the latest version of the js file.

Another option is that you have a CDN above Drupal, and it's the CDN caching the js file.

@trebormc, I resolved it by running the update again. Thanks for your help.

Works great, thanks.

I also recognized that the core form-ids have changed from underscore to hyphen. This should be updated in the install config. Like from "user_pass" to "user-pass".

Thanks again for quick release

Automatically closed - issue fixed for 2 weeks with no activity.

What happens if bots implement the same shuffle reverse algorithm? It doesn't seem like the final solution.

I do have some spam signups again, so it might already be going on. Not many, but they are the typical spam signups where the name and e-mail share no relation (Name field does not match e-mail field) and they are all US based addresses and the list is of a Dutch language magazine.

Just got word from a client that they got hundreds of spam messages over the last 24 hours. All from `45.144.227.*`, all from Taiwan.

I also have spam submissions again.
@gaurav.kapoor, @mstef, @danrod can you reopen this issue and set status to "Needs work", please?

Done @Duwid

Do you have more more details about the spam that you are getting? I'll look into this tomorrow.

@danrod

I don't have anything additional to add but am also not sure what information would be useful. The spam submissions have been preserved (Webform).

We see the same as #51 describes, the update helped but not enough unfortunately.

I've seen a few bug reports like this where the fix has been to make the antibot_key scrambling more elaborate.

I wonder: is it known why the existing input[name="form_token"] XSRF token doesn't accomplish the needed anti-forgery goal? Excuse me if this is a dumb question. Given the energy invested in rolling a separate antibot_key I assume there is a reason, but am not sure what is the reason.

We got 200+ Spambot Submissions this night. We have rate limting active so that they did submit one post every three minutes that came through. It some kind of bitcoin spam:

 betreff: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
  e_mail1: emiliogervacio02@gmail.com
  hausnummer: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
  ihr_anliegen: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
  nachname: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
  ort: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
  plz: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
  strassennamen: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
  telefonnummer: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'
  vorname: '1.333810 BTC in Your Account! That’s $118683 Ready to Be Collected:::: https://da.gd/SE68TK'

Sadly Modsecurity did not capture the post requests as no rule was triggered.

I wonder if it would be an option to add a factor to the antibot-key dynamically based on time of the form get.
At the moment it looks like the key is static for the same ip-adress. Okay, this would impact caching but then the bot would need to use the new key each time a form is submitted.

We've received 500+ spam submissions today (11/22/2024) for one form that we have. We had to close the form.

Also was getting spammed like crazy from a single IP address today. Trying to use SQL injection

About 100 in few minutes. Disabled the forms for now whilst investigating.

Using version: 2.0.4

Antibot is more effective after this change than before, but can still be bypassed. If I have understood correctly, Antibot is bypassed by saving and transferring the key. This means that we need more variance in the key.

Suggestion:

Generate the antibot key using the form_token (does webform actually use form_token? I couldn't find one, in this case use the form_build_id). However, this would mean that the antibot key is generated and transmitted per form and no longer per page (but IMHO this does not require any major adjustment, there should also be no differences in caching, because the cache duration is analogous to form_token or form_build_id). Was there a reason why a separate key was generated back then?

Remark:

In issue #3406484, a condition was added as to whether an event isTrusted, which may also improve the quality.