Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JThan’s picture

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

I see those messages also when uploading a file.

soxofaan’s picture

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

srobert72’s picture

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.

JThan’s picture

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

jurcello’s picture

Version: 6.x-2.3-rc2 » 6.x-2.3-rc1
Component: User interface » Code
Status: Active » Needs review
FileSize
1.75 KB

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.

jurcello’s picture

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

soxofaan’s picture

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)

JThan’s picture

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.

jurcello’s picture

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

damjan.cvetan’s picture

Has anybody found any solution to this problem?

JThan’s picture

Not me :(. Still looking for a solution.

soxofaan’s picture

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

(better title)

grahamvalue’s picture

Am having the same problem.

Any updates?

grahamvalue’s picture

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.

kfritsche’s picture

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

parasolx’s picture

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.

mtraherne’s picture

*subscribing

BrockBoland’s picture

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():

// 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:

// 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()?

soxofaan’s picture

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

BrockBoland’s picture

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

soxofaan’s picture

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, ...)
MJD’s picture

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

spiritkarma’s picture

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

soxofaan’s picture

ndstate’s picture

Any solution? Should this be major priority?

alit’s picture

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

jurcello’s picture

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.

gianfrasoft’s picture

Subscribe

soxofaan’s picture

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.

boysetsfire’s picture

Subscribe, same problem :(

GreenReaper’s picture

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?

ndstate’s picture

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;
}
soxofaan’s picture

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

jurcello’s picture

Following patch might work.

jurcello’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

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

jurcello’s picture

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?

jurcello’s picture

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

jurcello’s picture

Status: Needs work » Needs review
FileSize
1.76 KB

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

drupalorg’s picture

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

ndstate’s picture

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

soxofaan’s picture

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?

katherinecory’s picture

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

jurcello’s picture

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.

SchwebDesign’s picture

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

subscribing.

chawl’s picture

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.

jurcello’s picture

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.

jurcello’s picture

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.

JThan’s picture

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

suffering drupal’s picture

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?

suffering drupal’s picture

Uninstalled 2.4 -> back to 2.3
SOLVED!

syoga’s picture

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

boon4376’s picture

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

RogerB’s picture

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.

sun.core’s picture

tanjerine’s picture

+1 subscribing.

acbramley’s picture

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.

imclean’s picture

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.

svinod999’s picture

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.

svinod999’s picture

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.

acbramley’s picture

Can we get a patch for the drupal 7 version?

imclean’s picture

Version: 6.x-2.4 » 6.x-2.x-dev
Status: Needs work » Needs review
FileSize
2.41 KB

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

Patch based on #51.

sylvaticus’s picture

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 ;-)

imclean’s picture

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.

acbramley’s picture

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.

bneil’s picture

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.

acbramley’s picture

FileSize
2.78 KB

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.

shythai’s picture

Status: Needs work » Needs review
huytp’s picture

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

Barry_Fisher’s picture

FileSize
2.78 KB

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

SilviuChingaru’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

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

apb1991’s picture

subscribing

nimi’s picture

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

Thanks!

jahsh’s picture

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

Rajesh Ashok’s picture

FileSize
2.33 KB

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

Rajesh Ashok’s picture

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.

wingsss’s picture

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.

kunaalr’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev
Status: Needs work » Needs review
FileSize
3.54 KB

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.

kunaalr’s picture

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.
kunaalr’s picture

Status: Needs work » Needs review
mybinaryromance’s picture

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

mikemadison’s picture

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.

joshintosh’s picture

Status: Needs review » Reviewed & tested by the community

Worked for me! thanks.

spouilly’s picture

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

chrisschaub’s picture

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

wundo’s picture

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

scotwith1t’s picture

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

soxofaan’s picture

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

pbonnefoi’s picture

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 ;)

paulhudson’s picture

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

imclean’s picture

#98 has some tabs instead of 2 spaces.

elvis2’s picture

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

thummel’s picture

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));
}

/**

mxh’s picture

#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.
Snufkinski’s picture

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

agileadam’s picture

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

mavaddat’s picture

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.

sunset_bill’s picture

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

puddyglum’s picture

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

hendrohwibowo’s picture

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

batje’s picture

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.

prakashsingh’s picture

#98 also worked for me.

Thanks..

derek_slis’s picture

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

mortona2k’s picture

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.

Liam Morland’s picture

Status: Needs work » Needs review
FileSize
2.58 KB

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.

kpaxman’s picture

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

mortona2k’s picture

Status: Needs review » Reviewed & tested by the community

#117 works great!

metafunk’s picture

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

fraweg’s picture

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

Liam Morland’s picture

Liam Morland’s picture

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.

Liam Morland’s picture

Status: Needs work » Needs review
FileSize
1.04 KB

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.

neclimdul’s picture

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?

Liam Morland’s picture

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.

neclimdul’s picture

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.

Liam Morland’s picture

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.

Rob230’s picture

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

jay.dansand’s picture

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.

ts145nera’s picture

#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

Liam Morland’s picture

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

szecsodimlaszlo’s picture

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

Thanks.

macman’s picture

Hi

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

Thanks

Liam Morland’s picture

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

Liam Morland’s picture

Reroll.

wundo’s picture

Could anyone with a valid environment validate #135?

Long Nguyen’s picture

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

Long Nguyen’s picture

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

Liam Morland’s picture

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.

elsteff1385’s picture

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

Liam Morland’s picture

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

andrewtweber’s picture

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.

ajmalkhan’s picture

ajmalkhan’s picture

elachlan’s picture

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

elachlan’s picture

Status: Needs review » Reviewed & tested by the community

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

elachlan’s picture

Status: Reviewed & tested by the community » Patch (to be ported)
FileSize
1.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

neclimdul’s picture

db_update and db_select don't exist in d6

urbanlegend’s picture

Version: 7.x-1.x-dev » 6.x-2.5
FileSize
2.41 KB

Previous patch reapplied to 6.x branch

webservant316’s picture

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

webservant316’s picture

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.

elachlan’s picture

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.

knalstaaf’s picture

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.

neclimdul’s picture

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

elachlan’s picture

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.

Liam Morland’s picture

Issue summary: View changes
emmonsaz’s picture

#124 worked for me!

mourad-zitouni’s picture

#124 worked for mee too! thanks :)

The last submitted patch, 124: captcha-918856-session-reuse-124.patch, failed testing.

The last submitted patch, 124: captcha-918856-session-reuse-124.patch, failed testing.

Liam Morland’s picture

No point re-testing. The test will always fail now that it has been committed.

wundo’s picture

Yeah I know, I clicked re-test by mistake (I had too many tabs open).

Anonymous’s picture

#124 worked for mee too! thanks :)

Antoine Vigneau’s picture

According 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 have a form called in AJAX and displayed in a modal form (made using the ctools way)
  • In my form there is a field calling an ajax query to prepare another field
  • During the AJAX callback of this field, we go through captcha_element_process() twice
  • Consequently my captcha (Draggable Captcha) generate a new captcha codes/answer an so it's impossible to success to the Captcha

I will investigate but I'm pretty sure Draggable captcha is not guilty on this issue.

Liam Morland’s picture

Try to reproduce the problem using the math CAPTCHA. Disable other CAPTCHA modules and you can be sure of where the problem is.

Antoine Vigneau’s picture

Wow, 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!

vijayasri01’s picture

Version: 6.x-2.5 » 7.x-1.3

I am using captcha 7.x-1.3 and #90 patch worked for me. Thanks!

jasom’s picture

#1 from #2474959: CAPTCHA session reuse attack detected solved for me issue made probably by the latest drupal core ajax update

W.M.’s picture

What is the status for Drupal 7. Has this been fixed? Which patch should I apply? Thanks.

Liam Morland’s picture

This should be fixed as of 7.x-1.1.

crutch’s picture

Just 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 =

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

Both errors are not true, there is no reuse attack attempt and the answer to the math question is correct.

Milena B’s picture

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

Milena B’s picture

I 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

crutch’s picture

#90 patch worked but I think it is also supposed to remove

-> execute();

at line 660

so it should be

-        // Invalidate CAPTCHA token to avoid reuse.
-        db_update('captcha_sessions')
-          ->fields(array('token' => NULL))
-          ->condition('csid', $posted_captcha_sid);
-          -> execute();

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.

crutch’s picture

Status: Closed (fixed) » Needs work
naveenvalecha’s picture

Version: 7.x-1.3 » 7.x-1.x-dev
samstamport’s picture

None 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?

Liam Morland’s picture

Status: Needs work » Active

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

samstamport’s picture

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

koppie’s picture

Status: Active » Fixed

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

Status: Fixed » Closed (fixed)

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

broon’s picture

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

Liam Morland’s picture

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

broon’s picture

Update: 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:

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

crutch’s picture

Latest version is working fine here with mime mail 7.x-1.0-beta4 have not tested with 7.x-1.0

alexus’s picture

I'm still getting:

CAPTCHA session reuse attack detected.

$ drush -r . -l X pm-list | grep -i CAPTCHA
 Spam control         CAPTCHA (captcha)                          Module  Enabled        8.x-1.0-beta1  
 Spam control         Image CAPTCHA (image_captcha)              Module  Not installed  8.x-1.0-beta1  
 Spam control         reCAPTCHA (recaptcha)                      Module  Enabled        8.x-2.2        
$ 

Please advise.

Liam Morland’s picture

Please make a child issue if you are observing this in Drupal 8.