Is Eval a good guy or a bad guy?

Question

They talk a lot about eval, but sometimes I wonder if he really is the problem or is the person sitting in front of the computer (the supposed programmer).

My whole life (in programming) I have heard criticism, jokes, jokes about this function eval, but the curious thing is that, even those who mock, end up using libraries that use it internally, without knowing.

An example of this is Laravel 3, that in the system of views, uses eval.

Example (I removed the comments from the original code):

    public function get()
    {
        $__data = $this->data();

        $__contents = $this->load();

        ob_start() and extract($__data, EXTR_SKIP);

        try
        {
            eval('?>'.$__contents);
        }
        catch (\Exception $e)
        {
            ob_get_clean(); throw $e;
        }
        $content = ob_get_clean();

        if (Event::listeners('view.filter'))
        {
            return Event::first('view.filter', array($content, $this->path));
        }

        return $content;
    }

GITHUB - view.php - line 385

True, it is already discontinued, but it is not in a distant era (its version is for PHP 5.3). But it would come as no surprise if one of the critics of eval had using that framework unaware of this information.

And yet I give another example, that many programmers also use, but without knowing it. The Superclosure that is used in Laravel 4 and Laravel 5. This library aims to provide a possibility to serialize closures in PHP, since natively closures PHP does not support serialization. This library becomes useful for those who need to use queue systems, such as Beanstalkd, where the information passed is usually a string, and therefore PHP data needs to be serialized.

Example:

    /**
     * Reconstruct a closure.
     *
     * HERE BE DRAGONS!
     *
     * The infamous `eval()` is used in this method, along with the error
     * suppression operator, and variable variables (i.e., double dollar signs) to
     * perform the unserialization logic. I'm sorry, world!
     *
     * This is also done inside a plain function instead of a method so that the
     * binding and scope of the closure are null.
     *
     * @param array $__data Unserialized closure data.
     *
     * @return Closure|null
     * @internal
     */
    function __reconstruct_closure(array $__data)
    {
        // Simulate the original context the closure was created in.
        foreach ($__data['context'] as $__var_name => &$__value) {
            if ($__value instanceof SerializableClosure) {
                // Unbox any SerializableClosures in the context.
                $__value = $__value->getClosure();
            } elseif ($__value === Serializer::RECURSION) {
                // Track recursive references (there should only be one).
                $__recursive_reference = $__var_name;
            }
            // Import the variable into this scope.
            ${$__var_name} = $__value;
        }
        // Evaluate the code to recreate the closure.
        try {
            if (isset($__recursive_reference)) {
                // Special handling for recursive closures.
                @eval("\${$__recursive_reference} = {$__data['code']};");
                $__closure = ${$__recursive_reference};
            } else {
                @eval("\$__closure = {$__data['code']};");
            }
        } catch (\ParseError $e) {
            // Discard the parse error.
        }
        return isset($__closure) ? $__closure : null;
    }

Github - Serializableclosure.php - line 187.

Thinking about the usefulness of the classes of the libraries presented above, remembering that they are only two examples, but there must be other cases, I wondered if I should still speak bad of eval or simply make an analysis and evaluate when it is good or bad to use it.

On the other hand, if I think that "all of it, regardless of how it is implemented, is a risk", I will probably have to stop using the libraries I mentioned above, and do a whole manual job...

• What are the risks of using eval in a project?

• I must always avoid it?

• If the answer is yes to "should I avoid it," then should I also stop using libraries that implement it? After all, that can’t put my code at risk?

• The eval should be used in some very specific cases (such as code generation only) or I can use it freely, as long as I am aware of what I am doing?

Note: Please do not edit and put tags as php or Larable, for the examples were only to show cases where eval was "well received". If there are examples of other languages that use it, you are welcome.

Answer 1

I’m going to start by saying that people use libraries without knowing if they have quality or not. Thus, how they use techniques, tools, methodologies, paradigms, technologies, courses, etc. without knowing if it is good for him in that context.

What are the risks of using eval in a project?

With the injection of malicious code or data it is possible to compromise the entire execution system. The eval() will execute the text you receive without any concern. Often the programmer imagines that something reliable will come, but usually the opposite happens.

I must always avoid it?

Yes, must avoid it "always". But if you have a real need you can use if you know what you are doing.

If the answer is yes to "should I avoid it," then should I also stop using libraries that implement it? After all, that can’t put my code at risk?

If the library is well made there is not a big problem. I wonder if the library used this because her programmers are lazy or there was a real reason for its use. If it is the first, that reason alone should be a warning not to use this library.

The decision should go through an analysis of the code and see if they sanitized the entire input of the function properly. If this was done the danger is small. It can always fail. It may be that they did almost right, but they left a loophole that some change in the code could pave the way for a vulnerability.

The Eval should be used in some very specific cases (such as code generation only) or I can use it freely, as long as I am aware of what I am doing?

If you’re going to use code generation the right way, I have doubts if the eval() really necessary. If it is something that is not exposed, it is already something positive. You can even use it freely if you’re aware of what you’re doing, but if you are, you won’t use it unless it’s fundamental. Sanitizing can be more complicated than one imagines. Of course there are always exceptions, but when there is one, it was usually simple to solve without the eval() since you don’t need to sanitize anything.

Usefulness of the Eval()

I don’t remember a problem I had to deal with eval() were necessary except when I used a very bad language that did not allow other forms. Just to get an idea was a language that did not have array, function, and reference. The day that this language happened to have these things, everything was solved without evaluating source code at runtime.

Doing right by him is so complicated that doing right without him is just as easy. Almost all uses of the function only becomes simpler if it leaves gaps.

Deep down the eval() in itself is not the problem, at least no more than SQL. Of course the eval() allows to cause greater damage (but may even be less in certain cases). The danger is not sanitize the text.

It is obvious that in scripts own, internal, very simple things, or even in cases where the text source is controlled 100% by the application, its use may be minimally appropriate, although probably not yet necessary.

In addition to the security problem there are performance and maintenance problems. Therefore, even in cases where security is not an issue, we should not abuse.

The danger of it is that it is addictive. One likes to have apparently simplified work, and begins to abuse.

Javascript

Interestingly the staff speaks very badly of eval() in Javascript and in fact it is better to avoid it, but think about it, what difference it makes to have a eval() in a code that the user has full control of? The JS problem is further down. Of course I’m talking about the use in browser. If you use Node, Deno or other technology for use on backend, the eval() should be avoided, or at least use with perfect sanitizing.

Answer 2

Consider that every technique, pattern or programming philosophy you learn is a weapon.

Algorithms with data structures are a pistol, you need to learn how to handle at least that if you want to go to the front. Hence object orientation, which is a rifle - you only become an efficient soldier when you can assemble and disassemble your objects with your eyes closed. Design patterns are sniper rifles, you destroy specific problems very accurately. Algorithm analysis (understanding complexity and O notation) is a missile launcher - no matter how big the problem gets, you’ll spend the same ammunition to end it.

The eval is like an intercontinental ballistic nuclear missile:

• It has the potential to solve problems that would be very difficult to solve otherwise. In this case, adding external files, as Laravel does. However...
• Public opinion will hate you. You will hear from many people that what you are doing is an atrocity;
• There will be a lot of collateral damage: you are potentially opening your code to Javascript injection vulnerabilities. On the client side (browser) this is not so serious because in general all the code that runs in the browser is exposed to malicious people. But if you use JS on the server (Node.js, for example) and perform Eval on something that comes from the client side... May the God of programming have mercy on your soul;
• The radiation takes centuries to dissipate - the maintenance of your code gets more and more complicated, since:
  ** Virtually no code analysis tool will want to touch the eval;
  ** Debugging becomes much more complicated;
  ** Flows become more difficult to map.

Finally, I will speak from experience. Most of the time when people use eval, they could have solved their problems by other means. In an attempt to alleviate the problems mentioned above, they end up doing more things that are not recommended and the maintenance costs turn into a snowball. If you think about using the eval, make sure that your problems cannot be solved in any other way before taking the idea forward.