Tested in both 6.x-2.3-rc1 and 6.x-2.3-rc2.

When a user uploads more than one CCK FileField File, or ImageField Captcha throws 'session reuse attack detected'.
Going back to version 6.x-2.2 seems to fix the problem.

Files: 
CommentFileSizeAuthor
#150 captcha-918856-session-reuse-150.patch2.41 KBurbanlegend
#148 captcha-918856-session-reuse-147-do-not-test.patch1.04 KBelachlan
#136 captcha-918856-session-reuse-136.patch1.04 KBLiam Morland
PASSED: [[SimpleTest]]: [MySQL] 731 pass(es).
[ View ]
#124 captcha-918856-session-reuse-124.patch1.04 KBLiam Morland
PASSED: [[SimpleTest]]: [MySQL] 731 pass(es).
[ View ]
#117 captcha-918856-session-reuse.patch2.58 KBLiam Morland
PASSED: [[SimpleTest]]: [MySQL] 731 pass(es).
[ View ]
#103 captcha-patch-10022012.patch3.67 KBelvis2
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in captcha-patch-10022012.patch.
[ View ]
#98 captcha-ajax-support-918856-99.patch3.56 KBscotself
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch captcha-ajax-support-918856-99.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#90 captcha_ajax_support-918856-88.patch3.49 KBkunaalr
PASSED: [[SimpleTest]]: [MySQL] 731 pass(es).
[ View ]
#88 captcha_ajax_support-918856-88.patch3.54 KBkunaalr
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in captcha_ajax_support-918856-88.patch.
[ View ]
#83 918856-d7-captcha.patch2.33 KBRajesh Ashok
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 918856-d7-captcha.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#77 918856-d7-port.patch2.78 KBreallifedesign
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 918856-d7-port_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#72 918856-d7-port.patch2.78 KBacbramley
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 918856-d7-port.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#68 captcha.module.txt30.63 KBsylvaticus
#67 captcha_session_reuse-918856-67.patch2.41 KBimclean
PASSED: [[SimpleTest]]: [MySQL] 733 pass(es).
[ View ]
#51 captchaSessionReuseFix3.patch2.18 KBjurcello
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch captchaSessionReuseFix3.patch. See the log in the details link for more information.
[ View ]
#42 captchaSessionReuseFix2.patch1.76 KBjurcello
PASSED: [[SimpleTest]]: [MySQL] 910 pass(es).
[ View ]
#36 captchaSessionReuseFix.patch1.66 KBjurcello
FAILED: [[SimpleTest]]: [MySQL] 907 pass(es), 3 fail(s), and 0 exception(es).
[ View ]
#5 captcha.patch1.75 KBjurcello
FAILED: [[SimpleTest]]: [MySQL] 570 pass(es), 12 fail(s), and 0 exception(es).
[ View ]
captcha_plain_file_upload.JPG37.92 KBsolian
captcha_problem.JPG37.51 KBsolian

Comments

But 6.x-2.2 has a high security risk ( http://drupal.org/node/810534).

I see those messages also when uploading a file.

What happens when you fill in the CAPTCHA correctly before you attach/upload a file with the form?

Same problem with "Faceted_Search" module search forms.
I have same warning message when I launch search with "Captcha" module enabled.

I think it's not related with "FileField" module.
But maybe with "Boost" module who has recently changed its pages cache logic.

@soxofaan: Then the message does not appear. But how to tell that the customer? :)

@srobert72: I do not have Boost installed. So it should not be related.

Version:6.x-2.3-rc2» 6.x-2.3-rc1
Component:User interface» Code
Status:Active» Needs review
StatusFileSize
new1.75 KB
FAILED: [[SimpleTest]]: [MySQL] 570 pass(es), 12 fail(s), and 0 exception(es).
[ View ]

I have made a patch that could work (works with me with imagefields), but I'm not sure if this is ok.
Could anyone review this patch?

Status:Needs review» Needs work

The last submitted patch, captcha.patch, failed testing.

I see that the patch failed. Is the conclusion that this version of the captcha module is not compatible with filefield correct?

Version:6.x-2.3-rc1» 6.x-2.x-dev
Priority:Major» Normal
Status:Needs work» Needs review

the patch from #5 apparently breaks the session reuse detection

(please leave version of this thread to 6.x-2.x-dev)

The problem is when you hit Upload on filefield and do not fill in the captcha it somehow sends a value for that field anyway. I have added a watchdog message in line 494 of captcha.module to see this watchdog('captcha 494', $posted_captcha_sid); and it spits out a incremented number each time I hit upload. I do not know why but maybe someone else can find the bug with that information? I think my comment was not intelligent. Of course the sid is not the response (which I thought here at first) so that part works as coded. But still, somewhere there should be a check if this was a fileupload or not, I think.

I think the problem with filefield is as follows:
If you upload a file, the form is rebuild as a result of the ahah behavior of filefield. If you submit the form later on, it seems like there is a session reuse attack, because the captcha that is in the form was already used in the old form (before the rebuild by filefield).

If this is the case, there will be a problem with each module that uses ahah (and rebuilds the form).

Has anybody found any solution to this problem?

Not me :(. Still looking for a solution.

Title:Captcha Session Reuse message on FileField UploadsCaptcha Session Reuse message on FileField Uploads (AJAX form issue)

(better title)

Am having the same problem.

Any updates?

Version:6.x-2.x-dev» 6.x-2.3

Ok, this bug was proving costly.
So here's a temporary fix (or rather feature removal) till the actual fix arrives.

Delete or comment out the following lines of code in captcha.module

$expected_captcha_token = db_result(db_query("SELECT token FROM {captcha_sessions} WHERE csid = %d", $posted_captcha_sid));
if ($expected_captcha_token !== $posted_captcha_token) {
drupal_set_message(t('CAPTCHA session reuse attack detected.'), 'error');
// Invalidate the CAPTCHA session.
$posted_captcha_sid = NULL;
}
Works fine but I think now your captcha will be VULNERABLE to the reuse attack like in the earlier versions.

*subscribe
Why this check happens in the form process?
Shouldn't it be in the validate function?
When this move to the validate, then there shouldn't be an problem with the AHAH/Ajax call, or i'm totaly wrong? Didn't test it...

Issue tags:+boost, +ajax comment

i think the most practical solution is provide a button or link to refresh the captcha without need to refresh the whole page. like re-captcha option, they provide a button to refresh the captcha.

me also facing this problem with Boost + Ajax Comments. normal Drupal comment will refresh captcha since it change destination.

*subscribing

I'm seeing the same problem on a regular AHAH form (in my case, changing a Country dropdown uses AHAH to update the State/Province dropdown).

I don't yet understand this module well, but it looks like the block of code that throws this error should be moved into a validate function. This code is in _captcha_get_posted_captcha_info(), which is called from captcha_process(). That callback is set in captcha_elements():

<?php
// Define the CAPTCHA form element with default properties.
 
$captcha_element = array(
   
'#input' => TRUE,
   
'#process' => array('captcha_process'),
   
// The type of challenge: e.g. 'default', 'none', 'captcha/Math', 'image_captcha/Image', ...
   
'#captcha_type' => 'default',
   
'#default_value' => '',
   
// CAPTCHA in admin mode: presolve the CAPTCHA and always show it (despite previous successful responses).
   
'#captcha_admin_mode' => FALSE,
   
// The default CAPTCHA validation function.
    // TODO: should this be a single string or an array of strings (combined in OR fashion)?
   
'#captcha_validate' => 'captcha_validate_strict_equality',
  );
?>

I propose removing this block from _captcha_get_posted_captcha_info() info a function of its own, so that it won't be part of the #process function for that element:

<?php
// Check if the posted CAPTCHA token is valid for the posted CAPTCHA
// session ID. Note that we could just check the validity of the CAPTCHA
// token and extract the CAPTCHA session ID from that (without looking at
// the actual posted CAPTCHA session ID). However, here we check both
// the posted CAPTCHA token and session ID: it is a bit more stringent
// and the database query should also be more efficient (because there is
// an index on the CAPTCHA session ID).
if ($posted_captcha_sid != NULL) {
 
$expected_captcha_token = db_result(db_query("SELECT token FROM {captcha_sessions} WHERE csid = %d", $posted_captcha_sid));
  if (
$expected_captcha_token !== $posted_captcha_token) {
   
drupal_set_message(t('CAPTCHA session reuse attack detected.'), 'error');
   
// Invalidate the CAPTCHA session.
   
$posted_captcha_sid = NULL;
  }
 
// Invalidate CAPTCHA token to avoid reuse.
 
db_query("UPDATE {captcha_sessions} SET token=NULL WHERE csid=%d", $posted_captcha_sid);
}
?>

But from here, I'm not sure. Should this be added to captcha_validate()? Should it be added as $captcha_element['#validate'] in captcha_elements()?

@BrockBoland: I see you dared to dive into the code :)

I understand it looks like this code block belongs in the validation phase, but it is actually part of the form building phase. It is meant for a multi-page (or multi-preview situations), where we want to introduce a CAPTCHA session, spanning the multiple page views of the form. The code tries to detect (and protect against session reuse attacks) the current CAPTCHA session. This session info (including whether the the posted session should be invalidated because of a session reuse attack) is required for the rest of form building, so it can't be postponed to the validation phase.

Apart from that, note that the message 'CAPTCHA session reuse attack detected.' is just a message (not even a form error message), it doesn't block anything on its own and moving where this message is raised doesn't directly solve this issue.

The first part of the problem here is that AJAX usage implies that the full form is submitted several times. The CAPTCHA session reuse attack protection involves a CAPTCHA token on the form, which is unique for each submission. Now with AJAX, each time the form is submitted, a new token is generated server side (and expected on the next submit), but this new token is not set in the client side form. This means that each time the form is submitted (except the first time), the token is detected as wrong and the message 'CAPTCHA session reuse attack detected.' is raised. The fix for this part of the problem is to also make sure the CAPTCHA token is updated client side by the AJAX handling.

The second part of the problem is that you probably also want the AJAX stuff to work when the CAPTCHA isn't filled in yet. This is trickier to solve because, as far as I understand Drupal AJAX form handling, the form is validated and submitted as a whole, which wont succeed because the CAPTCHA response field is empty and consequently wrong.

How this can be solved needs more investigating and unfortunately I don't have the time at the moment to so, let alone fix it. I hope someone else can jump in here.

@soxofaan: Thanks for the follow up. I hadn't considered multi-page forms.

My understanding of the AHAH form handling is pretty hazy, too. I don't think that an AHAH call actually submits the form, but it does build the form by way of a drupal_get_form() call. I'd have to do some testing to be sure, but I think that the #process callback is run during the form build, not the form validate/submit, right?

And I too would love to help more with this bug if I had more time. Unfortunately, I've got too much on my plate right now, and commenting out the drupal_set_message() call worked for us - the validation still passes, so we're just suppressing the error message.

Title:Captcha Session Reuse message on FileField Uploads (AJAX form issue)CAPTCHA Session Reuse message on forms with AJAX funcionality (e.g. file upload, add another item, ...)

Just installed 6.x-2.3 on my test system...

If I logout I can't log back in!... not even via a different browser!

* CAPTCHA session reuse attack detected.
* The answer you entered for the CAPTCHA was not correct.

As I can't see whether the dev version offers a fix will revert back & wait for next release

I am trying to have math captchas on Webform 3.6's, AND comments. Problem is, if i want someone to comment ON a webform, then they are faced with TWO captcha fields, if they fill in one it says CAPTCHA REUSE ATTACK message. If they fill in BOTH captchas and just fill out the required comments field, it gives attack warning AND says you haven't filled in required fields on the webform itself. This behavior is exhibited whether or I not I have them go to a "separate page" for commenting. because, either way it previews the original post (THE WEBFORM!).

drupal version 6.20 LAMP + Captcha 2.3

Any solution? Should this be major priority?

#5: captcha.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+boost, +FileField, +Imagefield, +captcha, +Ajax, +ajax comment

The last submitted patch, captcha.patch, failed testing.

What patch #5 does is use the captcha which is generated in the first build of the form and put this captcha in the rebuilded form instead of the newly generated captcha.
If this is not allowed in the tests, the only solution is to somehow put the new image in the form using ajax, but this might be very complicated. I want to take a look at the tests if I have time. Maybe the test is to strict.

Subscribe

Any solution? Should this be major priority?

Hi all,
I'd like to make a note here to synchronize expectations and being up-front.
I'm the only maintainer of the CAPTCHA module currently. Drupal development is no my day job and I do this in my free time. At the moment, this free time is nearly non-existent and I mainly spend it to support in the issue queue and minor bug fixing.

I agree that the AJAX-issue in this thread is an important one, but it is also a pretty complex one to solve (see e.g. #20). I don't see myself finding an appropriate time slot to crack this issue in the short term, so I hope that someone else can step in here.

Subscribe, same problem :(

I have what I think is the same problem with AJAX Comments. On my site it actually allows the comment through, but appears to have failed to some users, causing them to make multiple posts.

I only require users to fill in one CAPTCHA correctly on my site anyway before giving them unrestricted posting. It may be slightly less secure but it works for me. In this situation, is it possible to somehow detect that the first preview in this user's session had a successful CAPTCHA and ignore subsequent token errors?

soxofaan, that is very understanding and I commend you on your great work so far. I would love to help, but I have very little knowledge that would be useful (though I would help with testing). Is it ok to comment out the following as a temporary fix?

$expected_captcha_token = db_result(db_query("SELECT token FROM {captcha_sessions} WHERE csid = %d", $posted_captcha_sid));
if ($expected_captcha_token !== $posted_captcha_token) {
drupal_set_message(t('CAPTCHA session reuse attack detected.'), 'error');
// Invalidate the CAPTCHA session.
$posted_captcha_sid = NULL;
}

@pmp6nl: that way you hide the message, but I'm afraid that things won't work properly. E.g. spam bots will be able to exploit the session reuse issue.

StatusFileSize
new1.66 KB
FAILED: [[SimpleTest]]: [MySQL] 907 pass(es), 3 fail(s), and 0 exception(es).
[ View ]

Following patch might work.

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch, captchaSessionReuseFix.patch, failed testing.

Version:6.x-2.3» 6.x-2.4
Status:Needs work» Needs review

I made this patch for version 6.x-2.4, so I changed the version. If the patch is still non-applicable, could someone try it?

#36: captchaSessionReuseFix.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+boost, +FileField, +Imagefield, +captcha, +Ajax, +ajax comment

The last submitted patch, captchaSessionReuseFix.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new1.76 KB
PASSED: [[SimpleTest]]: [MySQL] 910 pass(es).
[ View ]

Ok, last try for today. If this patch passes all the test, there is a strange issue concerning invalidating the CAPTCHA token.

#42: captchaSessionReuseFix2.patch queued for re-testing.

#42: captchaSessionReuseFix2.patch queued for re-testing.

I just tried jurcello patch from #42 on Core's "add poll" form (which uses AHAH to add new poll options).
It seems to work, meaning that the "CAPTCHA session reuse attack" message does not pop up, which is great.
I noticed a remaining issues however: if you don't fill in the CAPTCHA you still get a "CAPTCHA field is required" error message. I don't know if it is possible to solve this in Drupal6. For example, if you don't fill in the poll title and try to add a poll option, you also get a "title is required" error message, so this is caused by the way Drupal handles AHAH/AJAX as far as I know (submit+validation of complete form, even though only a subcomponent is required).

Can some other people try it out on their AJAX/AHAH powered forms?

I've applied patch #42 to a development site I'm working on and it's stopped the error message for me.

I think the problem concerning the poll form has nothing to do with the captcha module, but is a more general problem of the AHAH handling.

implemented patch #42 as well, fixed problem for me as well - nice work

subscribing.

If #42 is OK, then empty if statement should be omitted from the patch.
If #42 is for test only purposes, then one should use #36.
If smt is still broken for token invalidation, then this issue needs work, not review.
Confusing really.

This is indeed confusing. The empty if statement should be removed and the invalidation of the captcha session has to be done in a submit function. I will have a look at it when I have time.

StatusFileSize
new2.18 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch captchaSessionReuseFix3.patch. See the log in the details link for more information.
[ View ]

New patch in which the session is invalidated (in response to #49).

Status:Needs review» Needs work

The last submitted patch, captchaSessionReuseFix3.patch, failed testing.

I have tried the patch in #51 -> it worked for me. THX!

Not tried any patches yet (don't know how they work)
Getting the same as MJD #23 - directly on the register form.
By my knowing no strange ahas or ajaxes on that page. Disabled all surrounding blocks. Don't remember having problems with the former version but haven't tried seriously by then. NOW is when we decided to start accepting registrations.
Go back to former version?

Uninstalled 2.4 -> back to 2.3
SOLVED!

I had the same problem and it was solved by Using "Omit challenges in a multi-step/preview workflow once the user successfully responds to a challenge." as Default CAPTCHA validation in admin/user/captcha/captcha/settings

I am still having this problem with an ajax image upload on my form.

Happy to report that patch from comment #51 fixed my problem. Now able to upload files and images on forms containing a CAPTCHA without seeing the session reuse message.

+1 subscribing.

I have exactly the same issue with a multi page webform. The setting "Omit challenges in a multi-step/preview workflow once the user successfully responds to a challenge." did not fix the issue for me. The CAPTCHA message shows on the first page of the webform then once I click next page I get the error message.

I'm using the latest 7.x-1.x-dev of CAPTCHA and Core 7.8.

We were getting this error on a form with no AJAX, no file upload, no "add another item". Just a couple of text fields, including a select widget.

The code in #51 works for us, thanks. Perhaps resubmitting it as a git patch would help.

Status:Needs work» Needs review
Issue tags:-boost, -FileField, -Imagefield, -captcha, -Ajax, -ajax comment

#51: captchaSessionReuseFix3.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+boost, +FileField, +Imagefield, +captcha, +Ajax, +ajax comment

The last submitted patch, captchaSessionReuseFix3.patch, failed testing.

I got the "Session Reuse..." message while using Captcha with Ajax Comments on the comment form. A comment form submitted with the correct Captcha string and an incorrect required value in other field resulted in the required field error message. The form still had the same Captcha image and user input. When resubmitted the "Session Reuse... " error was thrown up.

Applying code from the patch from #51 fixed this. Though the image does not change, a session token is created and thus the "Session Reuse" error message does not appear.

Can we get a patch for the drupal 7 version?

Version:6.x-2.4» 6.x-2.x-dev
Status:Needs work» Needs review
StatusFileSize
new2.41 KB
PASSED: [[SimpleTest]]: [MySQL] 733 pass(es).
[ View ]

For git instructions, see http://drupal.org/node/8404/git-instructions/6.x-2.x

Patch based on #51.

For those of you that have problems in applying patches, here is the captcha module for 6.x-2.4 with the patch in #67.
I had to partially apply it manually as the second hunk failed over the 2.4 version.
Works fine to me (hierarchical select in registration form.. countries/regions like in #19), but use it at your own risk ;-)

sylvaticus, it isn't meant to apply to version 2.4. Grab the dev version via git using the instructions I linked to in #67.

Still getting this in the latest dev release on the 7.x branch. I think #1285096: "CAPTCHA session reuse attack detected" message when form not complete is also related to this.

I applied the patch in #67 to the 2.x branch and it fixed my issue.

However, I did get a whitespace error:

captcha_session_reuse-918856-67.patch:29: trailing whitespace.

Checking patch captcha.module...
Applied patch captcha.module cleanly.
warning: 1 line adds whitespace error.

StatusFileSize
new2.78 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 918856-d7-port.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I've tried porting this to Drupal 7 but am having a bit of trouble. This patch applies to the latest 7.x-1.x release. It seems to change the same things as the 6.x patch does but it doesn't seem to work. Any help would be much appreciated.

Status:Needs review» Needs work
Issue tags:-boost, -FileField, -Imagefield, -captcha, -Ajax, -ajax comment

The last submitted patch, 918856-d7-port.patch, failed testing.

Status:Needs work» Needs review

#72: 918856-d7-port.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+boost, +FileField, +Imagefield, +captcha, +Ajax, +ajax comment

The last submitted patch, 918856-d7-port.patch, failed testing.

StatusFileSize
new2.78 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 918856-d7-port_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

@acbramley There was a small issue with your patch in that you were trying to access a property of the database result returned rather than using the array index returned by fetchAssoc()

The line:

$captcha_token = $captcha_token->token;

Should be:

$captcha_token = $captcha_token['token'];

I've now applied your patch with this small change and I no longer get the session re-use problem when using custom Form API #ajax calls. Thanks!

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch, 918856-d7-port.patch, failed testing.

subscribing

Worked for me! Had to patch the file manually though...

Thanks!

None of these have worked for me. Is there a fix in the near future?

StatusFileSize
new2.33 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 918856-d7-captcha.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

#77 worked for me in drupal 7. I too applied the patch manually.

I have re-created the patch file (for #77) and uploading here.

Thank you reallifedesign.

Status:Needs work» Needs review

Status:Needs review» Needs work
Issue tags:-boost, -FileField, -Imagefield, -captcha, -Ajax, -ajax comment

The last submitted patch, 918856-d7-captcha.patch, failed testing.

Status:Needs work» Needs review

#83: 918856-d7-captcha.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+boost, +FileField, +Imagefield, +captcha, +Ajax, +ajax comment

The last submitted patch, 918856-d7-captcha.patch, failed testing.

Version:6.x-2.x-dev» 7.x-1.x-dev
Status:Needs work» Needs review
StatusFileSize
new3.54 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in captcha_ajax_support-918856-88.patch.
[ View ]

These changes need to be applied to the 7.x branch.
I've manually applied the changes after checking out the 7.x branch, its working for me without any issues so far.

Hope this helps.

Status:Needs review» Needs work

The last submitted patch, captcha_ajax_support-918856-88.patch, failed testing.

StatusFileSize
new3.49 KB
PASSED: [[SimpleTest]]: [MySQL] 731 pass(es).
[ View ]

Ran dos2unix on the file

patch applies cleanly without warnings now

~/Sites/captcha/captcha$ git apply -v captcha_ajax_support-918856-88.patch
Checking patch captcha.module...
Applied patch captcha.module cleanly.

Status:Needs work» Needs review

patching file captcha.module
Hunk #1 succeeded at 220 (offset 4 lines).
Hunk #2 FAILED at 353.
Hunk #3 succeeded at 438 (offset 2 lines).
Hunk #4 FAILED at 477.
Hunk #5 FAILED at 487.
Hunk #6 succeeded at 558 (offset 2 lines).
3 out of 6 hunks FAILED --

this is the patch from #90, directly applied on server

still, it solved the problem for me...

I couldn't get git to patch beyond the first hunk. I manually patched, but it looks like several items in this patch are already in the code, so that's strange.

Regardless, it does appear that this patch addresses the problem with ajax actions.

I still get the same session reuse message if the "preview" option is available and used on the page.

Status:Needs review» Reviewed & tested by the community

Worked for me! thanks.

Note: the patch apply cleanly to the dev version (7.x-1.x-dev) of the captcha module (works for me for the version of july 17th 2012).

Patch works for me as well. Seems good to commit.

Status:Reviewed & tested by the community» Needs work

patching file captcha.module
Hunk #5 FAILED at 490.
1 out of 6 hunks FAILED -- saving rejects to file captcha.module.rej

Please reroll the patch

StatusFileSize
new3.56 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch captcha-ajax-support-918856-99.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Rerolled the patch. Seems to work great. If folks could confirm and we could get this committed, that'd be swell :)

Status:Needs work» Needs review

there seem to be some whitespace issues in the patch

but let's first see what the test bot thinks

Status:Needs review» Needs work

Seems to work with my installation as well. I'm not sure if I have tested all the possibilities yet.
Thanks for the patch ;)

#98 works fine for me against the current 7 dev.
I'm using it on the user register form with a file upload field.

Good job!

#98 has some tabs instead of 2 spaces.

StatusFileSize
new3.67 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in captcha-patch-10022012.patch.
[ View ]

Here is a cleaned version of #98, without the tabs. I can confirm the patch works against captcha dev version (2012-Aug-08).

I'm still having this problem with version 7.x-1.0-beta2. The patch fails with:
Hunk #6 succeeded at 559 with fuzz 1 (offset 2 lines).
3 out of 6 hunks FAILED -- saving rejects to file captcha.module.rej

Reject file:
@@ -354,6 +364,9 @@
// Get placement in form and insert in form.
$captcha_placement = _captcha_get_captcha_placement($form_id, $form);
_captcha_insert_captcha_element($form, $captcha_placement, $captcha_element);
+
+ // Add #submit functions to invalidate captcha
+ $form['#submit'][] = 'captcha_submit_invalidate_session';
}
}
else if (
@@ -478,7 +505,7 @@
* @return TRUE when equal (ignoring spaces), FALSE otherwise.
*/
function captcha_validate_ignore_spaces($solution, $response) {
- return preg_replace('/\s/', '', $solution) === preg_replace('/\s/', '', $response);
+ return preg_replace('/\s/', '', $solution) == preg_replace('/\s/', '', $response);
}

/**
@@ -488,7 +515,7 @@
* @return TRUE when equal (ignoring spaces), FALSE otherwise.
*/
function captcha_validate_case_insensitive_ignore_spaces($solution, $response) {
- return preg_replace('/\s/', '', drupal_strtolower($solution)) === preg_replace('/\s/', '', drupal_strtolower($response));
+ return preg_replace('/\s/', '', drupal_strtolower($solution)) == preg_replace('/\s/', '', drupal_strtolower($response));
}

/**

#98 works for me aswell with current dev version. I think this patch needs only to be cleaned up.
Patch from #103 gives me following error:

patching file 'captcha.module'
patch unexpectedly ends in middle of line
Hunk #6 succeeded at 560 with fuzz 1.

I'm having the same problem (#104) as me.

Env.
Drupal 7.16
CAPTCHA 7.x-1.0-beta2

$ cd /home/example.com/public_html/D7_test/sites/all/modules/captcha
$ wget http://drupal.org/files/captcha-patch-10022012.patch
$ patch < captcha-patch-10022012.patch
(Stripping trailing CRs from patch.)
patching file captcha.module
Hunk #1 succeeded at 220 (offset 4 lines).
Hunk #2 FAILED at 354.
Hunk #3 succeeded at 440 (offset 2 lines).
Hunk #4 FAILED at 478.
Hunk #5 FAILED at 488.
patch unexpectedly ends in middle of line
Hunk #6 succeeded at 559 with fuzz 1 (offset 2 lines).
3 out of 6 hunks FAILED -- saving rejects to file captcha.module.rej

#67 worked great for me on 6.x-2.x-dev.

scotself's suggested patch in #98 works in correcting this error in version 7.x-1.0-beta2 as well. The only difference is that the two

=== preg_replace

were not necessary. Specifically,

-  return preg_replace('/\s/', '', $solution) === preg_replace('/\s/', '', $response);
+  return preg_replace('/\s/', '', $solution) == preg_replace('/\s/', '', $response);
and
-  return preg_replace('/\s/', '', drupal_strtolower($solution)) === preg_replace('/\s/', '', drupal_strtolower($response));
+  return preg_replace('/\s/', '', drupal_strtolower($solution)) == preg_replace('/\s/', '', drupal_strtolower($response));
are unnecessary.
Great work, scotself! I am sending you a high-five.

Confirming that #98 worked for me on the latest 7.x-1.x-dev (2012-Oct-29), too, even though I'm not doing any AJAX or image uploads.

scotself++

#98 works for me (I just removed the tabs)

patching file captcha.module
Hunk #1 succeeded at 220 (offset 4 lines).
Hunk #2 FAILED at 354.
Hunk #3 succeeded at 440 (offset 2 lines).
Hunk #4 FAILED at 478.
Hunk #5 FAILED at 488.
Hunk #6 succeeded at 559 (offset 2 lines).
3 out of 6 hunks FAILED -- saving rejects to file captcha.module.rej

patch #98, directly applied to server, captcha-7.x-1.0-beta2
works fine, no CAPTCHA session reuse attack detected

Thanks

I typed over patch 94 against our beta2 installation of the module and it does fix the issue. However in the watchdog we still see

"commerce_checkout_form_checkout post blocked by CAPTCHA module: challenge "Image" (by module "image_captcha"), user answered "", but the solution was "578mm""

which means that the captcha_validate function is still fired.

#98 also worked for me.

Thanks..

#103 (clean version of #98) worked for me. Error suppressed.
ENV: 7.19 - beta2

Using #103, I get these errors:
patching file captcha.module
Hunk #1 succeeded at 220 (offset 4 lines).
Hunk #2 FAILED at 358.
Hunk #3 succeeded at 443 (offset 2 lines).
Hunk #4 succeeded at 483 (offset 2 lines).
Hunk #5 FAILED at 493.
patch unexpectedly ends in middle of line
Hunk #6 succeeded at 562 with fuzz 1 (offset 2 lines).

But the patch does seem to work.

Status:Needs work» Needs review
StatusFileSize
new2.58 KB
PASSED: [[SimpleTest]]: [MySQL] 731 pass(es).
[ View ]

This patch is mostly a re-roll of the patch in #103. I have removed the part where it changes "===" to "==". I don't see how that change is related to the session reuse error message.

I can confirm the patch in #117 works for me.

Status:Needs review» Reviewed & tested by the community

#117 works great!

Any idea when this patch might be rolled into a release?

Hello,

#117 works for me but I get this error when I patch:

Hunk #2 FAILED at 356.

Best regards
Frank

Edit: With the current dev version 7.3 the patch runs without an issue...

Status:Reviewed & tested by the community» Needs work

With this patch, I am getting "CAPTCHA session reuse attack detected" errors on multi-page Webforms. Create a Webform with more than one page. Go to the next page (you'll have to pass the CAPTCHA). Go to the previous page and you will see the message.

Status:Needs work» Needs review
StatusFileSize
new1.04 KB
PASSED: [[SimpleTest]]: [MySQL] 731 pass(es).
[ View ]

This patch is much like the one in #117, but includes only the first hunk. In my testing with Webform, it seems to solve the Ajax problem this issue is about, but still works with multi-page Webforms. Please give it a try.

Is there an explanation of what's going wrong? I'm not seeing it and I'm having trouble reviewing because I don't understand the problem. Maybe a summary would help?

Basically, with the patch, the captcha_sessions table is only updated with a new captcha_token if there is not already an entry in that table for this form. You probably won't see the problem in a form unless it has Ajax multi-file uploading.

Well, that's not what's causing us to see it which is partially why I'm asking do we technically know what causes this to happen? I read the code and understood what it was doing but I don't understand why that's necessary because the bigger picture isn't evident from the code. IE. The subtle interactions between the formapi, the formapi validation and the CAPTCHA API's that causes this error to happen. Hope that's more clear.

I don't know in detail either. My patch is basically a re-roll of an earlier patch and it works as far as I can tell. I am not very familiar the the code overall. Perhaps the maintainer can weigh in here.

#124 has fixed the "session reuse attack detected" issue for me.

The site I'm testing on doesn't have any multi-part forms so I can't test that.

Would be great if this can be fast tracked to a release, as I prefer not to use patches or dev versions on production sites, but this issue is quite site breaking.

I hate having a bunch of unresolved patches making future updates difficult and error prone, so I went a different route to fix the issue and created a helper module that bypasses the problem. Basically, the CAPTCHA component is rendered on AJAX-submitted fields (in my case, "file/ajax" is the endpoint, provided by the File Upload field from the File module) but the CAPTCHA component does nothing useful here except burns up the form's CSID.

The problem flow is:

  1. Clicking "Upload" on the file field on the form issues an AJAX POST against the endpoint "file/ajax".
  2. "file/ajax" is a menu_router item in Drupal, which invokes the page callback file_ajax_upload()
  3. file_ajax_upload() calls drupal_process_form()
  4. drupal_process_form() calls form_builder()
  5. form_builder() calls _form_builder_handle_input_element(), which attempts to assign values to the form's components. My fix inserts itself here.
  6. form_builder() then checks some flags and calls captcha_element_process().
  7. captcha_element_process() always updates the table {captcha_sessions}, burning the session (CSID) on the form in the user's actual browser (since their version of the form won't update once the AJAX file upload callback returns).

So, I made a quick and dirty module to prevent the CAPTCHA component from rendering on "file/ajax" form builds. The CAPTCHA component does nothing useful there anyway, so we may as well stop it from rendering and causing future "CAPTCHA session reuse attack detected" error messages.

Check out the experimental fix module http://drupal.org/sandbox/dansandj/1970786 and let me know if it solves your problems. I can easily add support for more endpoints than just "file/ajax", just let me know.

#124 work for me but I must apply it manually because
Hunk #1 FAILED at 216.
I'm using 7.x-1.0-beta2+16-dev

The patch in #124 applies cleanly to 7.x-1.x from git.

Your sandbox module (#130) seems to work for me.

Thanks.

Hi

#124 didn't seem to match the code in 6.2.24. Has anyone got a fix for that?

Thanks

#124 is for 7.x-dev. It would have to be ported to D6.

StatusFileSize
new1.04 KB
PASSED: [[SimpleTest]]: [MySQL] 731 pass(es).
[ View ]

Reroll.

Could anyone with a valid environment validate #135?

Liam Morland,
We have the same issue on D6 for webform 6.x-2.24, do you know is there a patch for it?
"The answer you entered for the CAPTCHA was not correct.
CAPTCHA session reuse attack detected."

Title:CAPTCHA Session Reuse message on forms with AJAX funcionality (e.g. file upload, add another item, ...)CAPTCHA Session Reuse message on webforms
Version:7.x-1.x-dev» 6.x-2.4
Component:Code» Text Captcha (text_captcha)
Issue tags:-ajax webform form submit

We have the issue on D6 CAPTCHA 6.x-2.4 for webform 6.x-3.19, do you know is there a patch for it?
"The answer you entered for the CAPTCHA was not correct.
CAPTCHA session reuse attack detected."

Version:6.x-2.4» 7.x-1.x-dev

Bug are normally fixed in the current version, then the fixes are backported to older versions. You may be able to port my patch to Drupal 6.

Is this bug fixed in captcha 7.x-1.0 (released 26th of june)?

No, this patch has not been committed and I don't think this problem was fixed any other way.

Thanks, just want to confirm that this patch fixes the problem. In addition to AJAX file uploads, it also stopped the error from appearing on my multi page user registration form.

Can you also try and write a test for this use case?

Status:Needs review» Reviewed & tested by the community

Because of all the positive reviews. I am marking as RTBC.

Status:Reviewed & tested by the community» Patch (to be ported)
StatusFileSize
new1.04 KB

I have committed it to Git. Patch will need to be ported to 6.x and 8.x branches.

Here is the patch for 6.x

db_update and db_select don't exist in d6

Version:7.x-1.x-dev» 6.x-2.5
StatusFileSize
new2.41 KB

Previous patch reapplied to 6.x branch

Is this patch applied to 6.x-2.x-dev?
When I install 6.x-2.x-dev it is called 6.x-2.4+21-dev.
Shouldn't it be called 6.x-2.5+1-dev

ok I am going to hold on the upgrade and stay at 6.x-2.4 until I hear that this patch is in fact installed in dev or 2.6 is released.

If you test it and approve it I can patch the branch. I don't have much time right now to test stuff like this.

Is this bug fixed in captcha 7.x-1.0 (released 26th of june)?

Not in 7.x-1.0, but in 7.x-1.x-dev it's fixed.

applied and tested in 6.x. works as expected so far.

Status:Patch (to be ported)» Fixed

Committed to Git.

Status:Fixed» Closed (fixed)
Issue tags:-boost, -FileField, -Imagefield, -captcha, -Ajax, -ajax comment

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

Issue summary:View changes

#124 worked for me!