View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006550||OXID eShop (all versions)||1. ----- eShop frontend -----||public||2016-11-25 11:42||2016-12-08 15:33|
|Product Version||4.10.2 / 5.3.2|
|Target Version||Fixed in Version|
|Summary||0006550: Captcha generates sometimes wrong image while e_mac contains special characters|
|Description||On some installations the captcha image is generated with 4 chars instead of 5. Thus resulting in wrong form validation.|
I tracked down that the generated e_mac GET parameter which is generated by oxRegistry::getUtils()->strMan() may contain special chars. For example the generated image url could look like this: https://my-shop.com/core/utils/verificationimg.php?e_mac=ox_MB44HRFZNh4+
The plus sign at the end of this string will interpreted as " " (space sign) while its received by the verificationimg.php. This results in a wrong code generation.
An easy fix seems to urlencode the e_mac part. See attached patch file.
|Tags||No tags attached.|
|PHP Version||Not defined|
|MySQL Version||Not defined|
captcha_image_fix.patch.zip (442 bytes)
The arguments used in the call oxRegistry::getUtils()->strMan() in the Core/oxCaptcha::getImageUrl() method namely $key and $this->getText() are derived from the value of config.inc parameter "captchaKey"(Created during the Setup process) and the value of \oxCaptcha::$_sMacChars(hardcoded to be alphanumeric without any special characters) respectively. So it can be deducted that special characters are not by default behaviour possible in the shop.
Are there any special circumstances when a plus sign gets included in the string?
||strMan will call oxEncryptor->encrypt(). This function does an xor on both strings. The result is base64 encoded. The base64 character set includes '/' and '+'. So both characters are possible in the string and may break the verification img process.|