create_function can be a risk to my code?

Question

PHP from the version 5.3 has implemented the resource called funções anônimas or Closure.

Its use is this way:

$sort = function ($a, $b) { return $a - $b; };
$array = [1, 3, 2];
usort($array, $sort);

However, when it comes to previous versions, we do not have such a resource, and it is necessary to use two possible amending features:

• Create functions initialized by _ to identify that it is "temporary" or is only for callback.

Example:

function _sort($a, $b)
{
   return $a - $b;
}

usort($array, '_sort');

• Use the function create_function.

Example:

$lambda = create_function('$a, $b', 'return $a-$b;');
usort($array, $lambda);

In the latter case, my question comes, because this function uses eval internally. And that’s in the manual.

Example:

create_function('', 'ERRO_DE_SINTAXE_DE_PROPOSITO')

Exit will be:

PHP Parse error: syntax error, Unexpected '}' in phar:///usr/local/bin/psysh/src/Psy/Executionloop/Loop.php(76) : Eval()’d code(1) : Runtime-created Function on line 1

Therefore, on account of using the eval internally, is its use recommended? Or, in case of versions that do not exist Closure, should use the function with underline before?

Answer 1

You can use the function create_function, however you need to avoid problematic use cases of it. First, how this function uses eval internally, is very important that does not pass any data entered by the user, example:

$x = $_POST['user_input'];
$lambda = create_function('', 'return "O usuário digitou: ' . $x . '";');

Doing something like the above you leave a loophole for someone to execute arbitrary code on your system. It will go wrong!

Apart from the classic security problem of eval, create_function has another case with which you should be attentive, according to own documentation the function has bad performance and memory usage characteristics. So you definitely don’t want to invoke it within a widely used code chunk on your system - a loop or a central method that several other methods use for example.

As I wrote before, you can use the function, but you have to police yourself (and your colleagues ;]) not to generate a security problem, performance or memory leak.

As everyone eventually misses an hour, just do the same thing a sufficient number of times. It is probably wiser to stay away from her and stick to her convention of prefixing temporary functions with _.

Answer 2

From my point of view the premise of using eval() and create_function() is basically the same as what I have answered in:

• Why do they say $_GET in PHP is insecure against sql Injection?

The insecurity is in exposing to the user the use of this, or even exposing variant data entry of which you have no total control, for example:

$data = $_GET['data'];

$foo = create_function('$arg', "return $data == $y;");

echo $foo;

Then the user enters something like the URL:

http://site.com/foo.php?data=print_r%28%24_SESSION%29

Then it would be processed generated something like in $foo:

function () {
     return print_r($_SESSION) == $arg;
}

This way someone malicious could display all sensitive session data. Another example of exposing possibly sensitive data:

http://site.com/foo.php?data=var_dum%28pget_defined_constants%28%true%29%,get_defined_vars%28%%29%

Then it would be processed generated something like in $foo:

function () {
     return var_dump(get_defined_constants(true), get_defined_vars()) == $arg;
}

In all cases the problem is the exposure of the data input and not with the functions themselves.

---

Why not use create_function

Regardless of the safety issue the use of create_function is out of use since php7.2:

http://php.net/manual/en/function.create-function.php

This Function has been DEPRECATED as of PHP 7.2.0. Relying on this Function is highly discouraged.

this because for most cases a lambda/Closure function already solves everything and for the most complex data a string can behave with part of the language probably eval will resolve (which is rarely necessary, perhaps for a system of macro would be useful)