blocks|key|1539184|text|当您在eval中使用外部数据(如用户输入)时。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1539185|在上面的例子中，这不是问题。|1539186|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

When you are using foreign data (such as user input) inside the eval.

In your example above, this isn't an issue.

blocks|key|1324020|text|当只有极小的可能性将userinput包含在计算的字符串中时，eval就是邪恶的。当你在没有来自用户的内容的情况下进行eval时，你应该是安全的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1324021|然而，在使用eval之前，你至少应该三思而后行，它看起来很简单，但考虑到错误处理(参见VBAssassins注释)，可调试性等，它就不再那么简单了。|1324022|因此，经验法则是:忘了它吧。当eval是答案时，您可能问错了问题！;-)|1324023|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

eval is evil when there is only the slightest possibility that userinput is included in the evaluated string.
When you do eval without content that came from a user, you should be safe.

Nevertheless you should think at least twice before using eval, it looks deceivingly simple, but with error handling (see VBAssassins comment), debuggability etc. in mind, it is not so simple anymore.

So as a rule of thumb:
Forget about it. When eval is the answer you're propably asking the wrong question! ;-)

blocks|key|1539321|text|我也会对维护你的代码的人给予一些考虑。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1539322|eval()并不是仅仅查看并知道应该发生什么的简单方法，您的示例并不是那么糟糕，但在其他地方它可能是一个正确的噩梦。|1539323|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I'd also pay some consideration to people maintaining your code. 

eval() isn't the easiet to just look at and know what is supposed to happen, your example isn't so bad, but in other places it can be a right nightmare.

blocks|key|1539365|text|在这种情况下，eval可能是足够安全的，只要用户永远不可能在表中创建任意列。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1539366|不过，这并不是真正的优雅。这基本上是一个文本解析问题，滥用PHP的解析器来处理似乎有点老生常谈。如果您想滥用语言特性，为什么不滥用JSON解析器呢？至少在JSON解析器中，根本不可能有代码注入。|1539367|$json+=+str_replace(array(
++++'enum',+'(',+')',+"'"),+array)
++++'',+++++'[',+']',+"'"),+$type);
$result+=+json_decode($json);|code-block|syntax|javascript|1539368|正则表达式可能是最明显的方式。您可以使用一个正则表达式从该字符串中提取所有值：|1539369|$extract_regex+=+'/
++++(?<=,%7Cenum\()+++#+Match+strings+that+follow+either+a+comma,+or+the+string+"enum("...
++++\'++++++#+...then+the+opening+quote+mark...
++++(.*?)+++++++#+...and+capture+anything...
++++\'++++++#+...up+to+the+closing+quote+mark...
++++/x';
preg_match_all($extract_regex,+$type,+$matches);
$result+=+$matches[1];|1539370|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

In this case, eval is probably safe enough, as long as it's never possible for arbitrary columns to be created in a table by a user.

It's not really any more elegant though. This is basically a text parsing problem, and abusing PHP's parser to handle is seems a bit hacky. If you want to abuse language features, why not abuse the JSON parser? At least with the JSON parser, there's no possibility at all of code injection.

<pre><code>$json = str_replace(array(
 'enum', '(', ')', "'"), array)
 '', '[', ']', "'"), $type);
$result = json_decode($json);
</code></pre>

A regular expression is probably the most obvious way. You can use a single regular expression to extract all the values from this string:

<pre><code>$extract_regex = '/
 (?&lt;=,|enum\() # Match strings that follow either a comma, or the string "enum("...
 \' # ...then the opening quote mark...
 (.*?) # ...and capture anything...
 \' # ...up to the closing quote mark...
 /x';
preg_match_all($extract_regex, $type, $matches);
$result = $matches[1];
</code></pre>

blocks|key|1539455|text|eval将字符串评估为代码，问题是如果字符串以任何方式被“污染”，它可能会暴露出巨大的安全威胁。通常情况下，问题是在字符串中评估用户输入的情况下，在许多情况下，用户可以输入代码(例如php或ssi+)，然后在eval中运行，它将以与您的php脚本相同的权限运行，并可用于获取信息/访问您的服务器。在将用户输入传递给eval之前，确保用户输入被正确清理可能是相当棘手的。还有其他问题..。其中一些是有争议的|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1539456|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

eval evaluates a string as code, the problem with that is if the string is in any way "tainted" it could expose huge security threats. Normally the problem is in a case where user input is evaluated in the string in many cases the user could input code (php or ssi for example) that is then run within eval, it would run with the same permissions as your php script and could be used to gain information/access to your server. It can be quite tricky to make sure user input is properly cleaned out before handing it to eval. There are other problems... some of which are debatable

blocks|key|1539497|text|PHP建议您以这样的方式编写代码，使其可以通过call_user_func执行，而不是进行显式的eval。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1539498|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

PHP advises that you write your code in such a way that it can be executing via call_user_func instead of doing explicit evals.

blocks|key|1324411|text|我过去经常使用eval()，但我发现在大多数情况下，您不必使用eval来实现技巧。好的，在PHP中有call_user_func()和call_user_func_array()。它足够好，可以静态和动态地调用任何方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1324412|要执行静态调用，请将回调构造为数组(‘class_name’，'method_name')，甚至是像'class_name::method_name‘这样的简单字符串。要执行动态调用，请使用数组($object，'method')样式的回调。|1324413|eval()唯一合理的用法是编写一个自定义编译器。我做了一个，但是eval仍然是邪恶的，因为它太难调试了。最糟糕的是，计算代码中的致命错误导致调用它的代码崩溃。我使用Parsekit+PECL扩展至少检查了语法，但仍然没有乐趣-尝试引用未知的类和整个应用程序崩溃。|1324414|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I used to use eval() a lot, but I found most of the cases you don't have to use eval to do tricks. Well, you have call_user_func() and call_user_func_array() in PHP. It's good enough to statically and dynamically call any method.

To perform a static call construct your callback as array('class_name', 'method_name'), or even as simple string like 'class_name::method_name'. To perform a dynamic call use array($object, 'method') style callback.

The only sensible use for eval() is to write a custom compiler. I made one, but eval is still evil, because it's so damn hard to debug. The worst thing is the fatal error in evaled code crashes the code which called it. I used Parsekit PECL extension to check the syntax at least, but still no joy - try to refer to unknown class and whole app crashes.

blocks|key|1324434|text|eval是邪恶的另一个原因是，它不能被像eAccelertor或ACP这样的PHP字节码缓存。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1324435|entityMap^0|0|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Another reason <code>eval</code> is evil is, that it could not cached by PHP bytecode caches like eAccelertor or ACP.

blocks|key|1539603|text|让eval()变得邪恶的是糟糕的编程，而不是函数。我有时会使用它，因为我不能在多个站点上的动态编程中绕过它。我不能在一个网站上解析PHP，因为我不会收到我想要的东西。我只会收到一个结果！我很高兴有eval()这样的函数存在，因为它让我的生活变得容易得多。用户输入？只有糟糕的程序员才会被黑客勾搭上。我不担心这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1539604|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It's bad programming that makes eval() evil, not the function. I use it sometimes, as I can not get around it in dynamic programming on multiple sites. I can not have PHP being parsed at one site, as I will not receive the things I want. I would just receive a result! I'm happy a function as eval() exists, as it makes my life much more easy. User-input? Only bad programmers get hooked up by hackers. I don't worry about that.

blocks|key|1539624|text|这是一个不使用eval就可以运行从数据库中拉出的PHP代码的解决方案。允许范围内的所有函数和异常：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1539625|$rowId=1;++//database+row+id
$code="echo+'hello';+echo+'\nThis+is+a+test\n';+echo+date(\"Y-m-d\");";+//php+code+pulled+from+database

$func="func{$rowId}";

file_put_contents('/tmp/tempFunction.php',"<?php\nfunction+$func()+{\n+global+\$rowId;\n$code\n}\n".chr(63).">");

include+'/tmp/tempFunction.php';
call_user_func($func);
unlink+('/tmp/tempFunction.php');|code-block|syntax|javascript|1539626|基本上，它使用文本文件中包含的代码创建一个唯一的函数，包含该文件，调用该函数，然后在完成时删除该文件。我使用它来执行日常数据库摄取/同步，其中每一步都需要处理唯一的代码来处理。这解决了我面临的所有问题。|1539627|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Here is a solution to running PHP code pulled from a database without using eval. Allows for all in scope functions and exceptions:

<pre><code>$rowId=1; //database row id
$code="echo 'hello'; echo '\nThis is a test\n'; echo date(\"Y-m-d\");"; //php code pulled from database

$func="func{$rowId}";

file_put_contents('/tmp/tempFunction.php',"&lt;?php\nfunction $func() {\n global \$rowId;\n$code\n}\n".chr(63)."&gt;");

include '/tmp/tempFunction.php';
call_user_func($func);
unlink ('/tmp/tempFunction.php');
</code></pre>

Basically it creates a unique function with the included code in a text file, includes the file, calls the function, then removes the file when done with it. I am using this to perform daily database ingestions/syncronizations where every step requires unique code to handle to process. This has solved all the issues I was facing.

blocks|key|1539629|text|另一种选择|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1539630|参考：ClosureStream|offset|length|1539631|class+ClosureStream
{
++++const+STREAM_PROTO+=+'closure';

++++protected+static+$isRegistered+=+false;

++++protected+$content;

++++protected+$length;

++++protected+$pointer+=+0;

++++function+stream_open($path,+$mode,+$options,+&$opened_path)
++++{
++++++++$this->content+=+"<?php\nreturn+"+.+substr($path,+strlen(static::STREAM_PROTO+.+'://'))+.+";";
++++++++$this->length+=+strlen($this->content);
++++++++return+true;
++++}

++++public+function+stream_read($count)
++++{
++++++++$value+=+substr($this->content,+$this->pointer,+$count);
++++++++$this->pointer+%2B=+$count;
++++++++return+$value;
++++}

++++public+function+stream_eof()
++++{
++++++++return+$this->pointer+>=+$this->length;
++++}

++++public+function+stream_set_option($option,+$arg1,+$arg2)
++++{
++++++++return+false;
++++}

++++public+function+stream_stat()
++++{
++++++++$stat+=+stat(__FILE__);
++++++++$stat[7]+=+$stat['size']+=+$this->length;
++++++++return+$stat;
++++}

++++public+function+url_stat($path,+$flags)
++++{
++++++++$stat+=+stat(__FILE__);
++++++++$stat[7]+=+$stat['size']+=+$this->length;
++++++++return+$stat;
++++}

++++public+function+stream_seek($offset,+$whence+=+SEEK_SET)
++++{
++++++++$crt+=+$this->pointer;

++++++++switch+($whence)+{
++++++++++++case+SEEK_SET:
++++++++++++++++$this->pointer+=+$offset;
++++++++++++++++break;
++++++++++++case+SEEK_CUR:
++++++++++++++++$this->pointer+%2B=+$offset;
++++++++++++++++break;
++++++++++++case+SEEK_END:
++++++++++++++++$this->pointer+=+$this->length+%2B+$offset;
++++++++++++++++break;
++++++++}

++++++++if+($this->pointer+<+0+%7C%7C+$this->pointer+>=+$this->length)+{
++++++++++++$this->pointer+=+$crt;
++++++++++++return+false;
++++++++}

++++++++return+true;
++++}

++++public+function+stream_tell()
++++{
++++++++return+$this->pointer;
++++}

++++public+static+function+register()
++++{
++++++++if+(!static::$isRegistered)+{
++++++++++++static::$isRegistered+=+stream_wrapper_register(static::STREAM_PROTO,+__CLASS__);
++++++++}
++++}

}
ClosureStream::register();
//+Your+code+here!
$closure=include('closure://function(){echo+"hola+mundo";}');
$closure();|code-block|syntax|javascript|1539632|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/opis/closure/blob/master/src/ClosureStream.php^0|0|3|D|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@$D|U|E|V|1|W]]|A|$]]|$1|F|3|G|5|H|7|X|8|@]|9|@]|A|$I|J]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R]]]]

Another alternative
reference: <a href="https://github.com/opis/closure/blob/master/src/ClosureStream.php" rel="nofollow noreferrer">ClosureStream</a>
<pre><code>class ClosureStream
{
 const STREAM_PROTO = 'closure';

 protected static $isRegistered = false;

 protected $content;

 protected $length;

 protected $pointer = 0;

 function stream_open($path, $mode, $options, &amp;$opened_path)
 {
 $this-&gt;content = &quot;&lt;?php\nreturn &quot; . substr($path, strlen(static::STREAM_PROTO . '://')) . &quot;;&quot;;
 $this-&gt;length = strlen($this-&gt;content);
 return true;
 }

 public function stream_read($count)
 {
 $value = substr($this-&gt;content, $this-&gt;pointer, $count);
 $this-&gt;pointer += $count;
 return $value;
 }

 public function stream_eof()
 {
 return $this-&gt;pointer &gt;= $this-&gt;length;
 }

 public function stream_set_option($option, $arg1, $arg2)
 {
 return false;
 }

 public function stream_stat()
 {
 $stat = stat(__FILE__);
 $stat[7] = $stat['size'] = $this-&gt;length;
 return $stat;
 }

 public function url_stat($path, $flags)
 {
 $stat = stat(__FILE__);
 $stat[7] = $stat['size'] = $this-&gt;length;
 return $stat;
 }

 public function stream_seek($offset, $whence = SEEK_SET)
 {
 $crt = $this-&gt;pointer;

 switch ($whence) {
 case SEEK_SET:
 $this-&gt;pointer = $offset;
 break;
 case SEEK_CUR:
 $this-&gt;pointer += $offset;
 break;
 case SEEK_END:
 $this-&gt;pointer = $this-&gt;length + $offset;
 break;
 }

 if ($this-&gt;pointer &lt; 0 || $this-&gt;pointer &gt;= $this-&gt;length) {
 $this-&gt;pointer = $crt;
 return false;
 }

 return true;
 }

 public function stream_tell()
 {
 return $this-&gt;pointer;
 }

 public static function register()
 {
 if (!static::$isRegistered) {
 static::$isRegistered = stream_wrapper_register(static::STREAM_PROTO, __CLASS__);
 }
 }

}
ClosureStream::register();
// Your code here!
$closure=include('closure://function(){echo &quot;hola mundo&quot;;}');
$closure();
</code></pre>

In all the years I have been developing in PHP, I have always heard that using <code>eval()</code> is evil.
Considering the following code, wouldn't it make sense to use the second (and more elegant) option? If not, why?
<pre><code>// $type is the result of an SQL statement, e.g.
// SHOW COLUMNS FROM a_table LIKE 'a_column';
// hence you can be pretty sure about the consistency
// of your string.

$type = &quot;enum('a','b','c')&quot;;

// option one
$type_1 = preg_replace('#^enum\s*$\s*\'|\'\s*$\s*$#', '', $type);
$result = preg_split('#\'\s*,\s*\'#', $type_1);

// option two
eval('$result = '.preg_replace('#^enum#','array', $type).';');
</code></pre>

When is eval evil in php?

数据库

服务器

编译器

JSON

在我用PHP开发的这么多年里，我总是听说使用eval()是邪恶的。考虑到下面的代码，使用第二个(也是更优雅的)选项不是很有意义吗？若否，原因为何？// $type is the result of an SQL statement, e.g.// SHOW COLUMNS FROM a_table LIKE 'a_co...

问在php中，eval什么时候是邪恶的？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在php中，eval什么时候是邪恶的？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在php中，eval什么时候是邪恶的？
EN