Am having a problem where submissions that fail the CAPTCHA test are being reported in watchdog as

%form_id post blocked by CAPTCHA module: challenge "%challenge" (by module "%module"), user answered "%response", but the solution was "%solution".

This appears to be because the variables for the watchdog entry are getting corrupted. What seems to be happening is that the bot is posting a snippet of text from the page into the CAPTCHA box, including (I am guessing) a © symbol - using phpMyAdmin I can see the word Copyright in the serialized value of %response and it is followed by a space but then the variables entry seems to be truncated.

I've tried putting a © symbol in the CAPTCHA response on a dev site and I didn't hit this problem so I am not quite sure exactly what the bot is doing that is causing the problem.

Thanks for any insights!

Comments

soxofaan’s picture

soxofaan commented
Category: bug » support

Are all log entries like that or does the logging work for "normal wrong answers"?

What CAPTCHA type are you using?

gpk’s picture

gpk commented

Thanks for your reply. Logging works fine for normal wrong answers. Often the wrong answer (from a bot, or a real user) is an empty string, so we get the following log message:

contact_mail_page post blocked by CAPTCHA module: challenge "Math" (by module "captcha"), user answered "", but the solution was "15".

As I noted above, if I put a © in as the CAPTCHA answer then the logging works OK, so I am thinking that perhaps the bot is sending a malformed multibyte string in its form POST (this is just a guess really - I encountered something a little similar with string overrides module where import of strings failed when the strings contained multibyte characters. In that case, serialization similarly went haywire when the multibyte (accented) character was encountered.)

gpk’s picture

gpk commented
Category: support » bug

I'd say this is a bug, because a peculiar form submission by a bot shouldn't cause problems with CAPTCHA module's watchdog logging.

Is there any way I could capture the bot's form POST for subsequent analysis? Or should CAPTCHA simply use mb_check_encoding or iconv on the field submission? http://stackoverflow.com/questions/6723562/how-to-detect-malformed-utf-8...

soxofaan’s picture

soxofaan commented

Is it possible to extract the posted data from the database, as you described in your original message?

Apart from that, the CAPTCHA module uses standard Drupal core functionality here, so if it is a bug, it's probably a (maybe known) bug in Drupal core.
From captcha.module, around line 638:

        watchdog('CAPTCHA',
          '%form_id post blocked by CAPTCHA module: challenge "%challenge" (by module "%module"), user answered "%response", but the solution was "%solution".',
          array('%form_id' => $form_id,
            '%response' => $captcha_response, '%solution' => $solution,
            '%challenge' => $captcha_info['captcha_type'], '%module' => $captcha_info['module'],
          ),
          WATCHDOG_NOTICE
        );

(see http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/watchd...)

gpk’s picture

gpk commented

Here's the content of $variables from the database. It looks as if the bot has extracted some text from the page and posted it back. There is a space after the word Copyright. I have used string overrides to substitute the question text of the Math captcha, which seems to have fooled the bot :-D

a:5:{s:8:"%form_id";s:17:"contact_mail_page";s:9:"%response";s:82:"Adding 8 and 0 gives Copyright

As you can see we don't have a valid serialized array here. From previous experience my hunch is that the response string was malformed multibyte and that PHP's serialize fell over at the point the invalid byte sequence was encountered, and returned as much of the serialized $variables as had been constructed at that point.

Yes - this could be a core bug, though it is not clear to me whether it is core's responsibility to handle this situation or whether the caller should pass a valid $variables to watchdog. I suspect the core maintainers would say the latter.

gpk’s picture

gpk commented

Grateful for any suggestions as to how I can catch the response field in the form POST for subsequent analysis, to enable this problem to be taken further...

Thanks!

elachlan’s picture

elachlan commented
Issue summary: View changes
Status: Active » Closed (won't fix)