create_function can be a risk to my code?

2

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

Its use goes like this:

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

However, when it comes to the previous versions, we do not have a feature of this type, needing to use two possible alterative 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 create_function function.

Example:

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

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

Example:

create_function('', 'ERRO_DE_SINTAXE_DE_PROPOSITO')

Output 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

So, on account of using eval internally, is it recommended to use it? Or, for versions that do not exist Closure , should I use the function with the underline before?

    
asked by anonymous 19.11.2015 / 16:41

2 answers

1

You can use the create_function function, however you need to avoid problematic use cases. First, since this function uses eval internally, it is very important that no data entered by the user passes, eg:

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

Doing something like the above case, leaves a loophole for someone to execute arbitrary code on your system. It will hurt!

Aside from the classic security problem of eval , create_function has one more case that you should be aware of, according to the documentation itself the has bad performance and memory usage characteristics function. So you definitely will not want to invoke it within a snippet of code heavily used 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 stay policing yourself (and your colleagues;)) so as not to generate a security, performance, or memory leak issue.

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

    
25.05.2016 / 15:42
1

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

Insecurity is in exposing the user to the use of this, or even exposing variant data entry of which you do not have full control, for example:

$data = $_GET['data'];

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

echo $foo;

Then the user entered something like the URL:

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

Then it would be processed generated something like $foo :

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

In this way someone with malicious intent 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 $foo :

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

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

Why not use create_function

Regardless of the security issue, the use of create_function is deprecated since php7.2:

  

link

     

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

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

    
23.05.2018 / 17:14