Forms with AJAX trigger "CAPTCHA session reuse attack detected." error

related: #918856: CAPTCHA Session Reuse message on webforms

This patch did the trick for me. I have multiple AJAX/AHAH functions going on, which seemed to trigger the 'reuse attack' constantly--until I installed the patch, that is.

Good work!

This works for me as well. Thanks.

Not work for me...
After detect-ajax-form-7.x-1.x-2.patch "CAPTCHA session reuse attack detected" has gone, but "The answer you entered for the CAPTCHA was not correct" take place after patch...
And impossible to submit form.

#8 works for me

look to gotta it committed

#8 is not the right solution as noted in http://drupal.org/node/1024370#comment-5195128

However it should be fixed in 7.x-1.x-dev, see http://drupal.org/node/1024370#comment-5399482 (http://drupalcode.org/project/captcha.git/commit/ef22105)

I can confirm that this is not fixed in the latest -dev.

As noted, the patches in #3 and #8 don't seem to be the right solution. The real trouble seems to be that a new captcha token is generated every time the form is rebuilt -- but if the form is being rebuilt as the result of an ajax submission, that new token may well not be sent back with the response, so the next time the form is submitted, the token validation check will fail.

The attached patch fixes this by reusing the existing token if a form is submitted via ajax. I'm not a security expert, though, so I'm not sure what the implications of this are. It seems to me the only alternative is for Captcha to attach a process callback to every form with a captcha, and recursively replace every #ajax callback with one which also sends the new captcha token. Not impossible, but is it worth it?

This patch fixed the problem form me.

captcha-7.x-1.0-beta2-mcotelo.patch queued for re-testing.

patch #11 worked for me as well

The patch (#11) did not work for me. In my case, I have a form where when the country dropdown is changed, the whole form is refreshed since there are other fields being modified on the form by ajax. I am using 7.x-1.0-beta2+10-dev version.

Attached is a screenshot.

The same as #15 happens to me, "CAPTCHA Session reuse attack detected" when I click on the continent drop-down list.

Screenshot attached with the issue and the modules version.

#11 does not work for me (math captcha on AJAXed register form).

While I don't have much useful info to give, I can confirm that I am getting this bug as well when using it conjunction with http://drupal.org/project/hierarchical_select/

Have any one of the patches been confirmed as the proper approach?

Edit, sorry for the fragmented reply.

The patch in post 11 works to get rid of the captcha warning, but the ajax field that's kicking it off is now giving a "this field is required" error status in the same manner.

Solved for me

I was able to quell the errors that patch 11 left behind by only having one ajax element on the form. If there is a second ajax element (or hierachy select in my case) it tries to validate

I am also not recover my error.
While i am using ajax dependant dropdown with captcha (form API).
while populating dropdown it will also return an error.

"CAPTCHA session reuse attack detected."

Stuck.... Stuck.... Stuck....

I'm also seeing the same thing in beta2. I have it on a web form with no ajax loads involved. Captcha is unusable with this bug in place. upping the priority.

Also to note the watchdog listed this:
webform_client_form_14 post blocked by CAPTCHA module: challenge "Image" (by module "image_captcha"), user answered "e55mj", but the solution was "96c966862cf923fb2c9feb7a047327dd".

I of course entered the correct answer in my test so not sure where it's getting this info from.

Edit:
I just realized I do have an ajax file upload so thier is ajax on the form. None the less captcha is unusable for me keeping the priority raised.

#3: detect-ajax-form-7.x-1.x-2.patch queued for re-testing.

One antoher solution i found is "ajax callback"
create ajax callback for particular field and this will also refresh captcha image while ajax call.

$form['country'] = array(
'#ajax' => array('event' => 'change', 'callback' => 'modulename_country_callback'),
);

and

function modulename_country_callback($form, $form_state) {
return array(
'#type' => 'ajax',
'#commands' => array(
ajax_command_replace("#stateDiv", render($form['state'])),
ajax_command_replace("#load_captcha", render($form['captcha'])),
)
);
}

here #load_captcha is recall and image is change with ajax of one field is call.

my method

Can anybody please post the "PATCHED" version of module ?

Regards,
Amjad

Any news of the commitment of this patch?

I think the issue is that the patches don't seem to work for all cases. I know #11 didn't work for my situation.

#11 works in my case, but it seems like the real problem is that captcha is doing validation in the form #process step. Perhaps the session reuse check could be moved from _captcha_get_posted_captcha_info() to captcha_validate()?

In the code it is not clear why so much information is passed through to the front-end form and then retrieved from the front-end form, when it is also stored persistently in the $form_state; if this part of the code isn't clear, I can't effectively patch the bug.

#11 works for me (on branch 7.x-1.0-beta2)

Duplicate of #918856: CAPTCHA Session Reuse message on webforms .

#3 worked for me. Also, i didn't faced the problem mentioned in #7.

2 years ago, this issue may have been a duplicate. But the fix that was applied to make captcha work for webforms did not ultimately fix the problems that result when using custom ajax on forms that include a captcha field.

In #3, @mcotelo suggests that we can look at the #triggering_element for evidence that an ajax call has been made

In #11, @wodenx demonstrates that we also need to protect the regeneration of the persisted token as the root cause of the the "CAPTCHA session reuse attack detected." error that we receive is due to a mismatch of either token, or (earlier in the logic) a mismatch of actual vs stored form_id.

For me, today, the root cause of the problem is actually line 200 of captcha.module. Here it is in context:

  // Get the CAPTCHA session ID.
  // If there is a submitted form: try to retrieve and reuse the
  // CAPTCHA session ID from the posted data.
  list($posted_form_id, $posted_captcha_sid) = _captcha_get_posted_captcha_info($element, $form_state, $this_form_id);
  if ($this_form_id == $posted_form_id && isset($posted_captcha_sid)) {
    $captcha_sid = $posted_captcha_sid;
  }
  else {
    // Generate a new CAPTCHA session if we could not reuse one from a posted form.
    $captcha_sid = _captcha_generate_captcha_session($this_form_id, CAPTCHA_STATUS_UNSOLVED);
  }

When rebuilding the form, line 199 (that states list($posted_form_id, $posted_captcha_sid) = _captcha_get_posted_captcha_info($element, $form_state, $this_form_id); will return NULL for the form_id. I don't know why. That kind of doesn't make sense.

So here's a quick work around that fixes this bug for me.

Note: instead of using the triggering_element like #3 does, I'm checking to see if there is any rebuild info. I like this patch better than #11, because it's cleaner / reuses more of the existing logic / is smaller.

Let me know what you think.

(see attached)

#31 solves my issue with captcha on forms with multiple field values where 'add new item' and 'remove' were triggering session resuse errors.

#31 has solved my problem on a registration form with a file upload field. Thank you.

#31 has also solved my problem, on a form with a managed_file upload field. Thanks!

#31 solved my issue with addressfield on webforms when choosing country it ajax updates the form for the rest of the address.

#31 worked for me as well. Thank you.

The patch here looks like it fixes #2474959: CAPTCHA session reuse attack detected as well. Can we get a new release for the module?

+1 for a new stable release. This was a major problem.

Confirmed, the patch in #31 does resolve the issue. I agree that the fix should be expedited to the stable release as the bug completely cripples any form using it.

#31 patch works successfully for me. thanks for providing.

but i have a doubt. I'm not able to apply this patch using git commands which i use to do for others.
currently i have done it manually.

below is my command used. Could anyone please tell me what wrong I'm doing.

@WJNJINPB5YM8C /cygdrive/c/www/my-docroot/docroot/sites/all/modules/contrib
$ git apply --index ../patches/captcha-1395184_31.patch

It's not showing any error message but when i check the .module file, patch changes are not added.

Thanks in advance.

You need to be in the directory of the module you are patching when you run git apply.

This was a major problem for us as well. We tested the dev branch on a clean install as well as on several existing sites and it works properly.

This needs to be more prominent until it's included in a stable release.
If next release isn't coming out soon, I suggest adding this on the project page to get more attention from developers.

Thanks!

I agree with aramboyajyan.
But a stable release would be the best solution I think.

We have users who see this message "CAPTCHA session reuse attack detected."
This scares users into thinking something is wrong with the website. Couldn't this message be hidden?

Why does an error like this have to be shown to the user? Would make more sense to log this error message?

@joedevdrupal good point. I checked the code and by design that error should be displayed only when the user is really trying to reuse captcha and submit a passphrase for another session ID for example.

However, it still might make sense to make the message more generic, and log the error in the background. This way developers can still see the full error message in the logs, but potential attackers won't know that the system recognized what they're trying to do.

I'll give it some more thought and submit a patch if this does make sense for all use-cases.

That message is very annoying yes, but it's not really related to this problem, please open a separate issue.

It looks like this never made it into the Drupal 8 port, re-opening for that.

I'm not sure how the 7.x fix worked exactly but D8 can definitely not work like that because form state is no longer persisted.

I've been thinking about this for a while, also discussed it with @timplunkett and others. The best I could come up with for now is detecting such a form submission by checking if the triggering element has any validation error limits. If so, we simply don't do any processing at all, which would theoretically result in a broken captcha element but we don't care, since we assume that the captcha is already there and the result of what we do won't be shown.

This could have problematic side effects, like if the captcha is only actually added in such an ajax request, but I can't really imagine many use cases like that and so far, I see no other way. And if we really want to, we coud support a global flag like $form_state->set('process_captcha_always') or something.

Confused testbot is confused.

Hi,

I spend some time to fix this issue and just apply the patch #54, Its work good for me in drupal 8. Also, I raise the issue in https://www.drupal.org/node/810534.

Thanks for testing. The correct status for this is RTBC. It will be fixed when it is committed.

Added test.

This was RTBC? What was the need for the new patch?

Tests, like the comment says?

Also, the test only patch was an interdiff too, since it only contains test changes ;)

The test-only patch also has the change to CaptchaBaseWebTestCase::getMathCaptchaSolutionFromForm(), which is what prompted my comment.

That said, I think the changes in #58 look good, but I don't have a good way to double check this, so I don't feel comfortable setting RTBC.

@mpdonadio: "RTBC" means "Reviewed and Tested by the Community". It is one of the statuses that an issue can have.

I'm pretty sure that @mpdonadio knows that, he just asked why it was changed after being set to RTBC.

Test looks good to me and fails.

Sorry, I read his message as "What is RTBC?". I recall being confused the first time I heard the abbreviation.

Patch #54 patch works successfully for me. thanks for providing.

Confirmed patch #31 which already in 7.x-dev branch works form me, please make a new release.

We get tons of useless support requests because of this error. From a user standpoint, they feel like something was wrong or their file didn't upload.

Can maintainers just remove the error all together to the log level? Not sure why this is useful to the user other than confusion...

@joedevdrupal it should be fixed in the latest version. Please update?

@broadway I suggest you create a new issue specifically for that. It sounds like a browser issue though.

Thanks @elachlan I will make sure to update the module. Didn't know it was updated.

Like @broadway I'm using the 7.x 1.4 version and the error message is still displayed in Chrome desktop with anonymous user.
Release of 7.x 1.4 refers to this topic, but only 8.x has involved ?

Has anyone tried this with ReCaptcha? Google runs ReCaptcha