Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comments
Comment #1
JThan CreditAttribution: JThan commentedBut 6.x-2.2 has a high security risk ( http://drupal.org/node/810534).
I see those messages also when uploading a file.
Comment #2
soxofaan CreditAttribution: soxofaan commentedWhat happens when you fill in the CAPTCHA correctly before you attach/upload a file with the form?
Comment #3
srobert72 CreditAttribution: srobert72 commentedSame 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.
Comment #4
JThan CreditAttribution: JThan commented@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.
Comment #5
jurcello CreditAttribution: jurcello commentedI 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?
Comment #7
jurcello CreditAttribution: jurcello commentedI see that the patch failed. Is the conclusion that this version of the captcha module is not compatible with filefield correct?
Comment #8
soxofaan CreditAttribution: soxofaan commentedthe patch from #5 apparently breaks the session reuse detection
(please leave version of this thread to 6.x-2.x-dev)
Comment #9
JThan CreditAttribution: JThan commentedThe 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 thisI 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.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?Comment #10
jurcello CreditAttribution: jurcello commentedI 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).
Comment #11
damjan.cvetan CreditAttribution: damjan.cvetan commentedHas anybody found any solution to this problem?
Comment #12
JThan CreditAttribution: JThan commentedNot me :(. Still looking for a solution.
Comment #13
soxofaan CreditAttribution: soxofaan commented(better title)
Comment #14
grahamvalue CreditAttribution: grahamvalue commentedAm having the same problem.
Any updates?
Comment #15
grahamvalue CreditAttribution: grahamvalue commentedOk, 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.
Comment #16
kfritsche*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...
Comment #17
parasolx CreditAttribution: parasolx commentedi 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.
Comment #18
mtraherne CreditAttribution: mtraherne commented*subscribing
Comment #19
BrockBoland CreditAttribution: BrockBoland commentedI'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 fromcaptcha_process()
. That callback is set incaptcha_elements()
: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:But from here, I'm not sure. Should this be added to
captcha_validate()
? Should it be added as$captcha_element['#validate']
incaptcha_elements()
?Comment #20
soxofaan CreditAttribution: soxofaan commented@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.
Comment #21
BrockBoland CreditAttribution: BrockBoland commented@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.Comment #22
soxofaan CreditAttribution: soxofaan commentedFYI: another manifestation of this issue : #1032922: Clicking "Add another item" two times creates undefined solution
Comment #23
MJD CreditAttribution: MJD commentedJust 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
Comment #24
spiritkarma CreditAttribution: spiritkarma commentedI 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
Comment #25
soxofaan CreditAttribution: soxofaan commented@spiritkarma in #24: probably related to this issue: #995748: multiple CAPTCHA protected forms on same page gives "CAPTCHA session reuse attack detected."
Comment #26
ndstate CreditAttribution: ndstate commentedAny solution? Should this be major priority?
Comment #27
alit CreditAttribution: alit commented#5: captcha.patch queued for re-testing.
Comment #29
jurcello CreditAttribution: jurcello commentedWhat 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.
Comment #30
gianfrasoft CreditAttribution: gianfrasoft commentedSubscribe
Comment #31
soxofaan CreditAttribution: soxofaan commentedHi 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.
Comment #32
boysetsfire CreditAttribution: boysetsfire commentedSubscribe, same problem :(
Comment #33
GreenReaperI 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?
Comment #34
ndstate CreditAttribution: ndstate commentedsoxofaan, 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?
Comment #35
soxofaan CreditAttribution: soxofaan commented@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.
Comment #36
jurcello CreditAttribution: jurcello commentedFollowing patch might work.
Comment #37
jurcello CreditAttribution: jurcello commentedComment #39
jurcello CreditAttribution: jurcello commentedI 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?
Comment #40
jurcello CreditAttribution: jurcello commented#36: captchaSessionReuseFix.patch queued for re-testing.
Comment #42
jurcello CreditAttribution: jurcello commentedOk, last try for today. If this patch passes all the test, there is a strange issue concerning invalidating the CAPTCHA token.
Comment #43
drupalorg CreditAttribution: drupalorg commented#42: captchaSessionReuseFix2.patch queued for re-testing.
Comment #44
ndstate CreditAttribution: ndstate commented#42: captchaSessionReuseFix2.patch queued for re-testing.
Comment #45
soxofaan CreditAttribution: soxofaan commentedI 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?
Comment #46
katherinecory CreditAttribution: katherinecory commentedI've applied patch #42 to a development site I'm working on and it's stopped the error message for me.
Comment #47
jurcello CreditAttribution: jurcello commentedI 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.
Comment #48
SchwebDesign CreditAttribution: SchwebDesign commentedimplemented patch #42 as well, fixed problem for me as well - nice work
subscribing.
Comment #49
chawl CreditAttribution: chawl commentedIf #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.
Comment #50
jurcello CreditAttribution: jurcello commentedThis 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.
Comment #51
jurcello CreditAttribution: jurcello commentedNew patch in which the session is invalidated (in response to #49).
Comment #53
JThan CreditAttribution: JThan commentedI have tried the patch in #51 -> it worked for me. THX!
Comment #54
suffering drupal CreditAttribution: suffering drupal commentedNot 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?
Comment #55
suffering drupal CreditAttribution: suffering drupal commentedUninstalled 2.4 -> back to 2.3
SOLVED!
Comment #56
syoga CreditAttribution: syoga commentedI 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
Comment #57
boon4376 CreditAttribution: boon4376 commentedI am still having this problem with an ajax image upload on my form.
Comment #58
RogerBHappy 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.
Comment #59
sun.core CreditAttribution: sun.core commentedComment #60
tanjerine CreditAttribution: tanjerine commented+1 subscribing.
Comment #61
acbramley CreditAttribution: acbramley commentedI 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.
Comment #62
imclean CreditAttribution: imclean commentedWe 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.
Comment #63
svinod999 CreditAttribution: svinod999 commented#51: captchaSessionReuseFix3.patch queued for re-testing.
Comment #65
svinod999 CreditAttribution: svinod999 commentedI 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.
Comment #66
acbramley CreditAttribution: acbramley commentedCan we get a patch for the drupal 7 version?
Comment #67
imclean CreditAttribution: imclean commentedFor git instructions, see http://drupal.org/node/8404/git-instructions/6.x-2.x
Patch based on #51.
Comment #68
sylvaticus CreditAttribution: sylvaticus commentedFor 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 ;-)
Comment #69
imclean CreditAttribution: imclean commentedsylvaticus, it isn't meant to apply to version 2.4. Grab the dev version via git using the instructions I linked to in #67.
Comment #70
acbramley CreditAttribution: acbramley commentedStill 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.
Comment #71
bneil CreditAttribution: bneil commentedI applied the patch in #67 to the 2.x branch and it fixed my issue.
However, I did get a whitespace error:
Comment #72
acbramley CreditAttribution: acbramley commentedI'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.
Comment #74
shythai CreditAttribution: shythai commentedComment #75
huytp CreditAttribution: huytp commented#72: 918856-d7-port.patch queued for re-testing.
Comment #77
Barry_Fisher CreditAttribution: Barry_Fisher commented@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!
Comment #78
SilviuChingaru CreditAttribution: SilviuChingaru commentedComment #80
apb1991 CreditAttribution: apb1991 commentedsubscribing
Comment #81
nimi CreditAttribution: nimi commentedWorked for me! Had to patch the file manually though...
Thanks!
Comment #82
jahsh CreditAttribution: jahsh commentedNone of these have worked for me. Is there a fix in the near future?
Comment #83
Rajesh Ashok CreditAttribution: Rajesh Ashok commented#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.
Comment #84
Rajesh Ashok CreditAttribution: Rajesh Ashok commentedComment #86
wingsss CreditAttribution: wingsss commented#83: 918856-d7-captcha.patch queued for re-testing.
Comment #88
kunaalr CreditAttribution: kunaalr commentedThese 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.
Comment #90
kunaalr CreditAttribution: kunaalr commentedRan dos2unix on the file
patch applies cleanly without warnings now
Comment #91
kunaalr CreditAttribution: kunaalr commentedComment #92
mybinaryromance CreditAttribution: mybinaryromance commentedpatching 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...
Comment #93
mikemadison CreditAttribution: mikemadison commentedI 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.
Comment #94
joshintosh CreditAttribution: joshintosh commentedWorked for me! thanks.
Comment #95
spouilly CreditAttribution: spouilly commentedNote: 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).
Comment #96
chrisschaub CreditAttribution: chrisschaub commentedPatch works for me as well. Seems good to commit.
Comment #97
wundo CreditAttribution: wundo commentedpatching 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
Comment #98
scotwith1tRerolled the patch. Seems to work great. If folks could confirm and we could get this committed, that'd be swell :)
Comment #99
soxofaan CreditAttribution: soxofaan commentedthere seem to be some whitespace issues in the patch
but let's first see what the test bot thinks
Comment #100
pbonnefoi CreditAttribution: pbonnefoi commentedSeems to work with my installation as well. I'm not sure if I have tested all the possibilities yet.
Thanks for the patch ;)
Comment #101
paulhudson CreditAttribution: paulhudson commented#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!
Comment #102
imclean CreditAttribution: imclean commented#98 has some tabs instead of 2 spaces.
Comment #103
elvis2 CreditAttribution: elvis2 commentedHere is a cleaned version of #98, without the tabs. I can confirm the patch works against captcha dev version (2012-Aug-08).
Comment #104
thummel CreditAttribution: thummel commentedI'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));
}
/**
Comment #105
mxh#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:
Comment #106
Snufkinski CreditAttribution: Snufkinski commentedI'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
Comment #107
agileadam#67 worked great for me on 6.x-2.x-dev.
Comment #108
mavaddat CreditAttribution: mavaddat commentedscotself'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 twowere not necessary. Specifically,
and
are unnecessary.
Great work, scotself! I am sending you a high-five.
Comment #109
sunset_bill CreditAttribution: sunset_bill commentedConfirming 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++
Comment #110
puddyglum#98 works for me (I just removed the tabs)
Comment #111
hendrohwibowo CreditAttribution: hendrohwibowo commentedpatching 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
Comment #112
batje CreditAttribution: batje commentedI 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.
Comment #113
prakashsingh CreditAttribution: prakashsingh commented#98 also worked for me.
Thanks..
Comment #114
derek_slis CreditAttribution: derek_slis commented#103 (clean version of #98) worked for me. Error suppressed.
ENV: 7.19 - beta2
Comment #115
mortona2k CreditAttribution: mortona2k commentedUsing #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.
Comment #116
Liam MorlandMarking several issues duplicates of this:
#858902: CAPTCHA session reuse attack detected
#1023562: CAPTCHA session reuse attack detected.
#1285096: "CAPTCHA session reuse attack detected" message when form not complete
#1395184: Forms with AJAX trigger "CAPTCHA session reuse attack detected." error
#1522464: CAPTCHA session reuse attack detected error message when form is submitted
#1785442: Error message CAPTCHA session reuse attack detected.
Comment #117
Liam MorlandThis 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.
Comment #118
kpaxman CreditAttribution: kpaxman commentedI can confirm the patch in #117 works for me.
Comment #119
mortona2k CreditAttribution: mortona2k commented#117 works great!
Comment #120
metafunk CreditAttribution: metafunk commentedAny idea when this patch might be rolled into a release?
Comment #121
fraweg CreditAttribution: fraweg commentedHello,
#117 works for me but I get this error when I patch:
Best regards
Frank
Edit: With the current dev version 7.3 the patch runs without an issue...
Comment #122
Liam MorlandMarking #1934742: Drupal 7 AJAX and “CAPTCHA session reuse attack detected.” in captcha-7.x-1.x-dev as duplicate of this.
Comment #123
Liam MorlandWith 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.
Comment #124
Liam MorlandThis 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.
Comment #125
neclimdulIs 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?
Comment #126
Liam MorlandBasically, 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.
Comment #127
neclimdulWell, 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.
Comment #128
Liam MorlandI 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.
Comment #129
Rob230 CreditAttribution: Rob230 commented#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.
Comment #130
jay.dansand CreditAttribution: jay.dansand commentedI 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:
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.
Comment #131
ts145nera CreditAttribution: ts145nera commented#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
Comment #132
Liam MorlandThe patch in #124 applies cleanly to 7.x-1.x from git.
Comment #133
szecsodimlaszlo CreditAttribution: szecsodimlaszlo commentedYour sandbox module (#130) seems to work for me.
Thanks.
Comment #134
macman CreditAttribution: macman commentedHi
#124 didn't seem to match the code in 6.2.24. Has anyone got a fix for that?
Thanks
Comment #135
Liam Morland#124 is for 7.x-dev. It would have to be ported to D6.
Comment #136
Liam MorlandReroll.
Comment #137
wundo CreditAttribution: wundo commentedCould anyone with a valid environment validate #135?
Comment #138
Long Nguyen CreditAttribution: Long Nguyen commentedLiam 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."
Comment #139
Long Nguyen CreditAttribution: Long Nguyen commentedWe 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."
Comment #140
Liam MorlandBug 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.
Comment #141
elsteff1385 CreditAttribution: elsteff1385 commentedIs this bug fixed in captcha 7.x-1.0 (released 26th of june)?
Comment #142
Liam MorlandNo, this patch has not been committed and I don't think this problem was fixed any other way.
Comment #143
andrewtweber CreditAttribution: andrewtweber commentedThanks, 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.
Comment #144
ajmalkhan CreditAttribution: ajmalkhan commented#98: captcha-ajax-support-918856-99.patch queued for re-testing.
Comment #145
ajmalkhan CreditAttribution: ajmalkhan commented#98: captcha-ajax-support-918856-99.patch queued for re-testing.
Comment #146
elachlan CreditAttribution: elachlan commentedCan you also try and write a test for this use case?
Comment #147
elachlan CreditAttribution: elachlan commentedBecause of all the positive reviews. I am marking as RTBC.
Comment #148
elachlan CreditAttribution: elachlan commentedI 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
Comment #149
neclimduldb_update and db_select don't exist in d6
Comment #150
urbanlegend CreditAttribution: urbanlegend commentedPrevious patch reapplied to 6.x branch
Comment #151
webservant316 CreditAttribution: webservant316 commentedIs 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
Comment #152
webservant316 CreditAttribution: webservant316 commentedok 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.
Comment #153
elachlan CreditAttribution: elachlan commentedIf you test it and approve it I can patch the branch. I don't have much time right now to test stuff like this.
Comment #154
knalstaaf CreditAttribution: knalstaaf commentedNot in 7.x-1.0, but in 7.x-1.x-dev it's fixed.
Comment #155
neclimdulapplied and tested in 6.x. works as expected so far.
Comment #156
elachlan CreditAttribution: elachlan commentedCommitted to Git.
Comment #159
Liam MorlandMarking #2092863: CAPTCHA session reuse attack detected as duplicate of this.
Comment #160
emmonsaz CreditAttribution: emmonsaz commented#124 worked for me!
Comment #161
mourad-zitouni CreditAttribution: mourad-zitouni commented#124 worked for mee too! thanks :)
Comment #166
Liam MorlandNo point re-testing. The test will always fail now that it has been committed.
Comment #167
wundo CreditAttribution: wundo commentedYeah I know, I clicked re-test by mistake (I had too many tabs open).
Comment #168
Anonymous (not verified) CreditAttribution: Anonymous commented#124 worked for mee too! thanks :)
Comment #169
Antoine Vigneau CreditAttribution: Antoine Vigneau commentedAccording to 7.1 release notes: https://www.drupal.org/node/2298565
This fix is now included in the module. But is it true? Because I'm experiencing the same issue. Well I'm not sure it's exactly the same thing but it really looks like:
I will investigate but I'm pretty sure Draggable captcha is not guilty on this issue.
Comment #170
Liam MorlandTry to reproduce the problem using the math CAPTCHA. Disable other CAPTCHA modules and you can be sure of where the problem is.
Comment #171
Antoine Vigneau CreditAttribution: Antoine Vigneau commentedWow, actually you were absolutly right. It was working with Math, so I tried again with Draggable captcha, and he is definitly guilty, sorry for that.
Actually, when you drag the right shape, you don't have the green color to see that it's ok, but if you submit the form it works... That's definitly weird, I will check on my own, thanks!
Comment #172
vijayasri01 CreditAttribution: vijayasri01 commentedI am using captcha 7.x-1.3 and #90 patch worked for me. Thanks!
Comment #173
jasom CreditAttribution: jasom commented#1 from #2474959: CAPTCHA session reuse attack detected solved for me issue made probably by the latest drupal core ajax update
Comment #174
W.M. CreditAttribution: W.M. commentedWhat is the status for Drupal 7. Has this been fixed? Which patch should I apply? Thanks.
Comment #175
Liam MorlandThis should be fixed as of 7.x-1.1.
Comment #176
crutch CreditAttribution: crutch commentedJust completed upgrades and testing using math captcha 7.x-1.3 with core 7.50 and webform 7.x-4.13, still getting error with file upload by anonymous user. When captcha is disabled for the webform, then anonymous user is able to upload a file and submit the form successfully.
error =
Both errors are not true, there is no reuse attack attempt and the answer to the math question is correct.
Comment #177
Milena B CreditAttribution: Milena B as a volunteer commentedSame error,
•CAPTCHA session reuse attack detected.
•The answer you entered for the CAPTCHA was not correct.
•Attach a PDF copy of your paper: field is required.
Comment #179
Milena B CreditAttribution: Milena B as a volunteer commentedI created a form and tested it as anonymous user. The error message was:
•CAPTCHA session reuse attack detected.
•The answer you entered for the CAPTCHA was not correct.
•Attach a PDF copy of your paper: field is required.
captcha 7.x-1.3 (with CAPTCHA: challenge "Image" enabled)
core 7.43
webform 7.x-4.13
Comment #180
crutch CreditAttribution: crutch commented#90 patch worked but I think it is also supposed to remove
at line 660
so it should be
after testing this patch and removing that extra item it then works with
captcha 7.x-1.3
core 7.50
webform 7.x-4.13
Should this post be closed/fixed? I think it's not.
Comment #181
crutch CreditAttribution: crutch commentedComment #182
naveenvalechaComment #183
samstamport CreditAttribution: samstamport commentedNone of the patches fit the 7.x-1.3 version. Is there a patch for this version or has the patch been incorporated into it?
Comment #184
Liam MorlandIt was supposed to have been fixed as of 7.x-1.1; see comment #156 / commit 90e56c5. No patches have been submitted after that commit, so none of the patches should work with the current version.
If you are still having problems, please try to reproduce your problem with the latest captcha 7.x-1.x-dev on a fresh Drupal install.
I note the patch in #90 has some stuff in it that was not in the commit. Once you have reproduced the problem, you could try making some of those changes and see if the problem goes away.
This needs to be left on status "active" until there is a patch to review.
Comment #185
samstamport CreditAttribution: samstamport commentedReplacing 7.x-1.1 with the latest dev version seems to have fixed the problem.
I am now getting "captcha no challenge enabled" text on my admin home page, however. It does not appear on anonymous or user logins.
Comment #186
koppie CreditAttribution: koppie at Exygy for Cohere commentedI can confirm that upgrading to the latest dev version solves the problem.
We haven't had a stable release of this module since 2015, so hopefully we'll get one soon. In the mean time, I'm marking this issue as fixed.
Comment #188
broonI am using 7.x-1.4 and still experience this error even though this fix is stated to be included in 1.4; I downloaded dev version and it worked, so there might be some parts missing in 1.4.
Comment #189
Liam MorlandSomething strange is happening then. As of right now, 7.x-1.4 is tip of the 7.x-1.x branch, so it ought to be identical to the dev snapshot.
Comment #190
broonUpdate: CAPTCHA is working fine, the real culprit was the MimeMail module in my case. Sending an HTML mail failed and lead to an empty response which caused the reuse attack error messages in the CAPTCHA module.
Well, now it stopped working with 1.3+7-dev as well, upgrading to 1.4 again didn't help either. It's impossible to login (/user/login) or request a new password (/user/password) with captcha enabled. I tried with Math Captcha, reCaptcha, and DraggableCaptcha. Always the same message:Comment #191
crutch CreditAttribution: crutch commentedLatest version is working fine here with mime mail 7.x-1.0-beta4 have not tested with 7.x-1.0
Comment #192
alexus CreditAttribution: alexus as a volunteer commentedI'm still getting:
Please advise.
Comment #193
Liam MorlandPlease make a child issue if you are observing this in Drupal 8.