Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Antibot is effective at defeating basic bot submissions when the submission is made on the form itself. The potential weakness is when form data is POSTed remotely to the form endpoint. In a scenario like that, Antibot does not intervene in any way. A solution would be:
1) Generate a key for each form based on the form ID (ie, md5(form_id + time()) and store it in the form.
2) Add a hidden value element to each protected form with no value.
3) Pass the key to the JS settings.
4) Once a form is unlocked, the hidden value is set to the key.
5) Add a validation handler to verify that the key was provided.
6) Test to ensure that the form can still remain cached.
Doing this will stop any remote posts from passing validation. Yes, if an attacker really really wanted to target your specific site then these controls can be bypassed (but so can the regular Antibot protection; and pretty much all bot prevention).
| Comment | File | Size | Author |
|---|---|---|---|
| #31 | Selection_010.png | 30.32 KB | mstef |
| #17 | antibot2.PNG | 66.88 KB | System Lord |
| #2 | 2952198-2.patch | 3.88 KB | mstef |
Comments
Comment #2
mstef commentedQuick stab at it. It only uses an md5() of the form Id for the key. It would be better if it used something that changed over time but the challenge is keeping the form cacheable.
This also eliminates the need for the /antibot page controller since without JS, you'll never get there.
Edit: I take that last bit back. You'll still end up on the page because the incorrect action will bypass the form submission all together. This just adds an additional layer.
I also think that the md5 is stronger than the action change because the action is almost always just the current page path: which is predictable.
Comment #4
mstef commentedComment #6
mstef commentedLet's port this to 7.x to add extra security.
Comment #7
System Lord commentedI can't find where "FormStateInterface " is added to "function antibot_form_alter" in antibot.module.
Apologies up front. I install patches manually so I can't tell you if the patch install fails or not. I just noticed by reviewing the files that there's no place where "FormStateInterface " is added and there's no existing form_alter function with "FormStateInterface " in the dev (or stable version).
Comment #8
mstef commentedI haven't provided a 7.x patch for this yet. I want to get in the patch from #2934488: Do not modify the visual experience of the form for users with JavaScript first, which was your original issue.
Comment #10
mstef commentedCommitted to 7.x.
Comment #11
mstef commented@systemlord, is the view you reported the bug for in #2934488: Do not modify the visual experience of the form for users with JavaScript using AJAX?
Comment #12
mstef commentedCan you also show me the complete HTML of the form? I don't understand how antibot_key could be set but the input not be present.
Comment #13
mstef commentedForget my questions. I am able to reproduce.
Will need to test if this happens in 8.x as well.
Comment #14
mstef commentedFix coming. The one downside, because of how Views exposed filters work, is that the antibot_key will end up in the URL after you submit. There's really nothing I can do about it. I don't know of any other site using Antibot for Views exposed forms, since there's really no write operations that take place from submitting them (unlike comments, login, registration, etc).
Comment #16
mstef commentedCommitted.
Comment #17
System Lord commentedYep, AJAX is turned on for this block view.
HTML in attached image.
Comment #18
System Lord commented#14, I'll see what it does to the URL and let you know if it will be an issue. The upside, for me, is that I don't really need to apply Antibot to this Views search b/c I don't really think there's much interest for a bot, although I really don't know. Data gets input and the search query satisfies or it doesn't. But, if you can get it to work then great! All the better.
Comment #19
mstef commentedNew fix coming. The initial one allowed for this entire feature to potentially be bypassed.
Fix also needed for 8.x.
Comment #22
mstef commentedBoth branches are good now.
Comment #23
mstef commentedComment #24
System Lord commentedOk, I'll redo test for #20. #15 did fix it, but I understand #19.
For the next fews days I'll be doing full site testing hard! I'll let you know if any issues arise.
Thanks mstef! Great support!
Comment #25
System Lord commentedAs for #14, I haven't seen anything different with the URLs. So far, all works perfectly.
Comment #26
mstef commentedWith AJAX, you won't. Without it, you will.
Comment #27
mstef commentedFor reference, this feature seems to do more than just protect against remotely-posted forms. In D7, at least, the user login block seems to be able to be submitted without JS until this feature was implemented. I'm not sure why that one is able to get through with the incorrect form action.
Comment #28
System Lord commented#27 works. I disabled JS and the login form remained present, but after submitting my UID/PWD it jumped right to /antibot page. A nice thing about this is that the failed attempt didn't make it to my dblog, so there's no way to flood it. I didn't check watchdog, though.
If I may....
Change:
To:
Bolded is only for you.
#26, understood
Comment #29
mstef commentedAvoiding even a dblog entry is the reason to use the form action switch as the primary method of bot diversion. It completely kills the form submission process which is the lightest outcome for your site.
As for the text change, let's keep this ticket only about the issue described here. We can open other issues for other topics. But what I will say, is that there's no way everyone will agree on what the string should be. This string really doesn't matter. The only way a human sees it is if they have JS disabled, they use a tool to reveal a hidden form, and still decide to submit the form any way. It might as well just say "..really?".
Alter hooks or contrib modules can be used to override strings pretty easily.
Comment #30
System Lord commentedI haven't tested this, but thinking about #28, is it the same for all forms? I.e., a user (without JS) could fill out a long form only to discover this warning...and lose all the info they entered into the form? That would suck! But, this would be an acceptable trade-off. This isn't an issue for my site b/c my users have to get past login to reach my forms, which would mean they have already passed the JS test. Others might have an issue with this "trade-off."
#29, good points. I just can't help myself :)
Comment #31
mstef commentedIf you have JS disabled, you should not see the form, and only see a warning message.
See attached.
If that's not happening for you, then there's a problem.
Comment #32
System Lord commentedWheww! Ok, my bad. I haven't been "disabling" JS. I've been preventing antibot.js from running (Chrome inspector). I just went into Chrome and fully disabled JS then refreshed the page and what is displayed in your image above is what I now see. Hmm I'm going to have to run through my previous testing now. Tomorrow.
Comment #33
System Lord commentedI just discovered a bonus of Antibot. My site falls apart without JS. Before Antibot there was nothing displayed informing my users why...no "JavaScript must be enabled." Now there is :) This is due to me having views_exposed_form on every page, which triggers Antibot on ever page.
The warning "You must have JavaScript enabled to use this form" won't make sense to them, but they will understand that JS must be enabled, which is good enough.