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.

Original bug report:

I've experienced problems with CAPTCHA 7.x-1.0-beta1 in forms with AJAX: CAPTCHA could never be solved (see http://drupal.org/node/1024370, #9 helped me with that).

Now, in beta2, there is another problem. If a form has AJAX, and you change the element that triggers de AJAX, you get this message: "CAPTCHA session reuse attack detected.".

I've found that _captcha_get_posted_captcha_info() uses $form_state['submitted'] to detect a submitted form. An AJAX 'submitted' form does not have that flag, so I think $form_state['triggering_element'] should be used, instead. Patch is attached.

I had to apply the change in http://drupal.org/node/1024370#comment-4159970 too, but I did not include it in the attached patch, because it breaks other things.

Files: 
CommentFileSizeAuthor
#60 interdiff-52-58.txt2.93 KBmpdonadio
#58 captcha-ajax-1395184-58.patch4.05 KBArla
#58 captcha-ajax-1395184-58-TEST_ONLY.patch3.1 KBArla
#54 captcha-ajax-1395184-52.patch969 bytesBerdir
#52 captcha-ajax-1395184-52.patch969 bytesBerdir
#31 1395184_31.patch1.08 KBcosmicdreams
PASSED: [[SimpleTest]]: [MySQL] 718 pass(es). View
#19 captcha.jpg112.27 KBvimalgoradiya
#16 Screenshot Capcha issue 02_07_2012.png42.05 KBvalery86
#15 Screenshot from 2012-06-16 22:54:45.png84.64 KBelvis2
#11 1395184-11-captcha-ajax.patch3.21 KBwodenx
PASSED: [[SimpleTest]]: [MySQL] 731 pass(es). View
#3 detect-ajax-form-7.x-1.x-2.patch1.17 KBmcotelo
PASSED: [[SimpleTest]]: [MySQL] 718 pass(es). View
captcha-7.x-1.0-beta2-mcotelo.patch848 bytesmcotelo
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch captcha-7.x-1.0-beta2-mcotelo.patch. Unable to apply patch. See the log in the details link for more information. View

Comments

soxofaan’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, captcha-7.x-1.0-beta2-mcotelo.patch, failed testing.

mcotelo’s picture

FileSize
1.17 KB
PASSED: [[SimpleTest]]: [MySQL] 718 pass(es). View

Attaching a new patch.

mcotelo’s picture

Status: Needs work » Needs review

Have you tried the last patch I sent?
Is there something I have to do, or something I can help you with?

tomogden’s picture

Status: Needs review » Reviewed & tested by the community

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!

natuk’s picture

This works for me as well. Thanks.

kernel32ddl’s picture

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.

mcotelo’s picture

@kernel32ddl, yes I had that problem too, and I had to apply two changes, the one I posted, and the one in http://drupal.org/node/1024370#comment-4159970

hibersh’s picture

#8 works for me

look to gotta it committed

soxofaan’s picture

wodenx’s picture

Version: 7.x-1.0-beta2 » 7.x-1.x-dev
Status: Reviewed & tested by the community » Needs review
FileSize
3.21 KB
PASSED: [[SimpleTest]]: [MySQL] 731 pass(es). View

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?

guy_schneerson’s picture

This patch fixed the problem form me.

santhosh.murugesan’s picture

nbucknor’s picture

patch #11 worked for me as well

elvis2’s picture

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.

valery86’s picture

Version: 7.x-1.x-dev » 7.x-1.0-beta2
FileSize
42.05 KB

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.

mpdonadio’s picture

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

patrickavella’s picture

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

vimalgoradiya’s picture

FileSize
112.27 KB

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....

danielphenry’s picture

Priority: Normal » Major

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.

sitaram10’s picture

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

vimalgoradiya’s picture

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.

frompasttofuture’s picture

amjad1233’s picture

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

Regards,
Amjad

warmth’s picture

Any news of the commitment of this patch?

mpdonadio’s picture

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.

becw’s picture

Status: Needs review » Needs work

#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.

muka’s picture

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

Liam Morland’s picture

Status: Needs work » Closed (duplicate)
bhavikshah9’s picture

Issue summary: View changes

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

cosmicdreams’s picture

Status: Closed (duplicate) » Needs review
FileSize
1.08 KB
PASSED: [[SimpleTest]]: [MySQL] 718 pass(es). View

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)

cosmicdreams’s picture

Issue summary: View changes
cosmicdreams’s picture

Issue summary: View changes
tko’s picture

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

szecsodimlaszlo’s picture

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

charginghawk’s picture

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

dobe’s picture

Status: Needs review » Reviewed & tested by the community

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

wundo’s picture

wundo’s picture

Status: Reviewed & tested by the community » Fixed

  • wundo committed 9d33018 on 7.x-1.x authored by cosmicdreams
    Issue #1395184 by mcotelo, cosmicdreams, wodenx, vimalgoradiya, valery86...

Status: Fixed » Closed (fixed)

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

madelyncruz’s picture

#31 worked for me as well. Thank you.

PapaGrande’s picture

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

Anybody’s picture

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

RayCascella’s picture

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.

venkateshakarle’s picture

#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.

Liam Morland’s picture

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

aramboyajyan’s picture

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!

Anybody’s picture

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

joedevdrupal’s picture

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?

aramboyajyan’s picture

@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.

Berdir’s picture

Version: 7.x-1.0-beta2 » 8.x-1.x-dev
Status: Closed (fixed) » Needs review
FileSize
969 bytes

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.

Status: Needs review » Needs work

The last submitted patch, 52: captcha-ajax-1395184-52.patch, failed testing.

Berdir’s picture

Confused testbot is confused.

Berdir’s picture

Status: Needs work » Needs review
Rajamohamed A’s picture

Status: Needs review » Fixed

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.

Berdir’s picture

Status: Fixed » Reviewed & tested by the community

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

Arla’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
3.1 KB
4.05 KB

Added test.

The last submitted patch, 58: captcha-ajax-1395184-58-TEST_ONLY.patch, failed testing.

mpdonadio’s picture

FileSize
2.93 KB

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

Berdir’s picture

Tests, like the comment says?

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

mpdonadio’s picture

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.

Liam Morland’s picture

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

Berdir’s picture

Status: Needs review » Reviewed & tested by the community

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.

Liam Morland’s picture

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

poojasharmaece’s picture

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

weynhamz’s picture

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

  • elachlan committed 955872b on 8.x-1.x authored by Arla
    Issue #1395184 by Berdir, mcotelo, Arla, cosmicdreams, wodenx, mpdonadio...
elachlan’s picture

Status: Reviewed & tested by the community » Fixed