WordPress.org

Ready to get started?Download WordPress

Forums

Really Simple CAPTCHA
Comments on change in 1.4 (7 posts)

  1. DerManu
    Member
    Posted 2 years ago #

    Hi,
    I'm a bit stumped at how you solved the problem of people being able to access the .txt files and read the captcha as text. Including a temporary .php file - even worse, with a name generated from input of the website user - to set a variable is kind of dangerous.
    The typical programming pattern in such a case would be to still save into the .txt file, but save two values: first n characters a salt, i.e. a string containing random alphabet/number chars, next 64 characters a hash of the captcha string concatenated with the salt.
    So when you want to check the correctness of $input, you load the .txt file content to a string, extract the first n characters to $salt, and check hash('sha256', $input . $salt) against the last 64 characters of the string. (If you're not familiar with the technique, look for hash function and cryptographic salt at wikipedia.)
    That would be alot safer than what you're doing now.

    http://wordpress.org/extend/plugins/really-simple-captcha/

  2. Takayuki Miyoshi
    Member
    Plugin Author

    Posted 2 years ago #

    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?

  3. DerManu
    Member
    Posted 2 years ago #

    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.

  4. DerManu
    Member
    Posted 2 years ago #

    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.

  5. Takayuki Miyoshi
    Member
    Plugin Author

    Posted 2 years ago #

    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.

  6. DerManu
    Member
    Posted 2 years ago #

    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.

  7. Takayuki Miyoshi
    Member
    Plugin Author

    Posted 2 years ago #

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

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic