Add support for reCAPTCHA Enterprise

I added a patch that creates a new service "Enterprise.php" with the functionality for enterprise.

The last submitted patch, 2: recaptcha-enterprise-3449033-2.patch, failed testing. View results →

resubmit the patch as previous one was failing the tests

I'm adding a new patch that can be used on the stable version

Hello @aalin,

This patch doesn't apply.

Seems recaptcha classic will go soon: https://cloud.google.com/recaptcha/docs/migrate-recaptcha

I have tried making a new key in Google Cloud Console and the website key did not work - recaptcha field then shows invalid website key.

Will this issue fix this or should I open new one?

I'm still on `drupal/recaptcha` version 3.2.0 and confirmed that the patch in #5 applies cleanly to that. Looks like there have been some significant updates since 3.2.0 causing a need for the patch to be re-rolled or officially supported as an option by the maintainers.

I have a Google Cloud Project with an Enterprise reCAPTCHA API account and I created a new public site key following these instructions: https://cloud.google.com/recaptcha/docs/create-key-website#create-key

When you create the public site key like that, the GCP admin console doesn't provide you with the private secret key to pair with the public key for the server-side token verification step, like it once did in the classic/legacy reCAPTCHA admin console (before a GCP with an active billing account was required). Now to get the private secret API key, you have to go into the GCP's APIs & Services > Credentials https://console.cloud.google.com/apis/credentials to create the private secret API key.

Of the 5 types of REST authentication methods mentioned here https://cloud.google.com/docs/authentication/rest#types_of_credentials, at the bottom they say you can authenticate with only an API_KEY as the “key” query string parameter. https://cloud.google.com/docs/authentication/rest#api-keys

The patch in #5 performs this server-side request made from Drupal directly to the reCAPTCHA Enterprise REST API create assessment endpoint https://cloud.google.com/recaptcha/docs/create-assessment-website, so it's not be exposed to network traffic visible by the client browser.

One thing I noticed about that patch, though, is it's only checking if `$api_response['tokenProperties']['valid'] == true`, but that only indicates that the provided user response token generated by the client-side `grecaptcha.enterprise.execute` is valid. It doesn't really tell you if it's a bot or not. When `valid == false`, the `reason` is specified in `invalidReason`. Google's documentation also says `valid = false` can also indicate that a user has failed to solve a challenge or there is a `siteKey` mismatch.

https://cloud.google.com/recaptcha/docs/interpret-assessment-website

I think two things should be checked in combination with checking if `valid == true`:

1. The bot likelihood `score`. This is going to be different for every site, but they recommend starting out with `0.5`. Anything greater than `0.5` and closer to `1.0` is likely human and anything less than that closer to `0.0` is likely a bot. This value should be made to be configurable in the reCAPTCHA Drupal admin settings form and added to the response handling logic in `Enterprise.php`.

2. The client-side `action` from a user interaction that triggered a reCAPTCHA v2 verification in the first place needs to be compared to the `expectedAction` on the server-side response from the create assessment REST API. Google's documentation says if these don't match, it indicates that an attacker is attempting to falsify actions. You can take actions against the user interaction, such as adding additional verifications or blocking the interaction to prevent any fraudulent activities. Perhaps this `action` could infer some unique `form_id` about the Drupal form it's rendered on and then the server-side `expectedAction` could validate that against a known list of valid actions.

I have tried the patch recaptcha-enterprise-from-stable-3449033-5.patch on Drupal 10.3.1-dev, and it doesn't get applied.

Hey @sandeep_k not sure if you saw what I mentioned above, but it applies to version 3.2.0 of the drupal/recaptcha module, not the latest version.

Also I have some concerns because it's not actually checking the bot score in the response from the Enterprise reCAPTCHA create assessment API.

Hi
I have tried the patch recaptcha-enterprise-from-stable-3449033-5.patch on Drupal 10.3. x-dev,
And Patch is throwing an error, which needs to be fixed for the latest version.

Thanks!

Started a merge request that rerolls the last patch to the last version of the reCAPTCHA module and adds some small improvements.
Have not had the time to go over the comments/concerns of @wesleymusgrove

Thx @jonjacobs! I'm interested to look at your MR. The short version of my concern is that it's not checking the bot likelihood score or the expected action on the enterprise API response, which means that bots can be scripted to simulate human mouse movements and click the correct pictures of stoplights and crosswalks, but reCAPTCHA will notice those repetitive mouse movements and give them a bot likelihood score of < 0.5. If that happens, you shouldn't consider it a valid form submission because it's a bot.

I have the patch from #5 applied and running on a production site. I've seen many FullStory screen recordings of bot sessions doing this exact thing and the enterprise API returns a bot score of `$api_response['riskAnalysis']['score'] = 0.1`, which means definitely a bot. But because the current code is only checking `$api_response['tokenProperties']['valid'] == true`, it's considering that a valid form submission and lets the bot continue doing whatever nefarious things it was going to do before we showed it the v2 captcha.

I'll leave some comments on your MR to hopefully clarify what I'm talking about.

I think your suggestions are great, @wesleymusgrove.

Hi @wesleymusgrove
Thanks for your comments, I've implemented them with some minor changes.
Also changed to javascript functions to use the enterprise version based on the use_enterprise setting

This patch is from MR !41 and applies to 8.x-3.4.

jonjacobs → closed merge request !40

Thanks for moving this along @wesleymusgrove. Nice rework of the JS.
I've closed the other MR, so there's no confusion.
I've done a quick test with the latest changes and seems to be working fine.

Minor updates to the patch from MR !41 that applies to 8.x-3.4.

New patch for a minor fix to the hook_update_N description comment.

Re-rolled the patch to:
- Update reCAPTCHA Human Score title, description, and link to not be v3-specific.
- Refactor waitForRecaptchaReady inside of the Drupal once so the same Promise code doesn't get attached multiple times every time BigPipe renders a block.
- Better handle multiple .g-recaptcha elements on a single page.
- Increase the maxWait timeout to 20 seconds for slow connections.