[Plugin: Really Simple CAPTCHA] Comments on change in 1.4

with a name generated from input of the website user

No, it’s not generated from input of the website user.

Using hashed text is one of ideas I thought. A demerit of the method is that generating hash is consuming more computing power. What will happen if an attacker tries DoS attack?

No, it’s not generated from input of the website user.

I disagree. Let’s take your Contact Form 7 for example:
on line 123 of modules/captcha.php you call wpcf7_check_captcha with the post parameter ‘_wpcf7_captcha_challenge_’ . $name. This parameter is a hidden field that is absolutely manipulatible by the user, i.e. with firebug or numerous other tools. This function passes this on to the function check() of an instance of the “really simple captcha” class, which finally turns this string into a filename.

Now regarding the performance of hash calculation: don’t worry. modern hash implementations work at a scale of microseconds. Even the generation of the captcha image – let alone writing it to disk – consumes orders of magnitude more time. And talking about increased vulnerability to DoS due to _two_ calls to a hash function seems a bit silly considering we’re talking about a wordpress site that launches myriads of classes, queries and algorithms for every page hit.

Anyway, I’m not dictating anything, it was just a suggestion.

A maybe better suggestion:
Write the captcha normally to .txt file like before, but don’t give 755 permission like currently in line 70 of really-simple-captcha.php (why the execute bit anyway?). Change the file mode of the .txt (not the .png of course) to 640 or even 600.
Since the process that reads the .txt is also the process that creates it, we will always have full 6 access, i.e. read and write. But unlike now, the rest of the world won’t have any access and receive a HTTP 403 Forbidden error.
This should solve the problem.

Sounds nice. I appreciate your suggestion. Let me consider it for the next update.

I have one more question about that. I’m still not sure why you consider the current method, generating temporary .php files, as dangerous. Do you have specific hacking scenarios? I just want to estimate the risk before making changes.

Since you pass $prefix through the sanitize filename function of wordpress (which luckily strips slashes), the threat is currently not so immediate. Still, including variable strings that can be changed from outside is very bad practice and may turn into a real include injection exploit some time in the future, when the environment in which your plugin runs, has changed. This is the typical source of such security holes. Imagine the wp guys decide in version 4.3.1 to allow paths in the sanitize filename function. This way one could include any php file on the system, possibly on other shared host accounts. If using relative dirs, you could include an arbitrary php file on any webserver, e.g. one the intruder has uploaded somewhere himself.

Thanks. I agree it’s better not use .php file as answer container. I’ll follow your suggestion.