我担心我的回答可能有点太消极了，但是……

恕我直言，每一个单独的函数和方法都可以用于邪恶的目的。可以将其视为邪恶的涓滴效应:变量被分配给用户或远程输入，变量被用于函数，函数返回值被用于类属性，类属性被用于文件函数，等等。记住:一个伪造的IP地址或中间人攻击可以利用你的整个网站。

Your best bet is to trace from beginning to end any possible user or remote input, starting with $_SERVER, $_GET, $_POST, $_FILE, $_COOKIE, include(some remote file) (if allow_url_fopen is on), all other functions/classes dealing with remote files, etc. You programatically build a stack-trace profile of each user- or remote-supplied value. This can be done programatically by getting all repeat instances of the assigned variable and functions or methods it's used in, then recursively compiling a list of all occurrences of those functions/methods, and so on. Examine it to ensure it first goes through the proper filtering and validating functions relative to all other functions it touches. This is of course a manual examination, otherwise you'll have a total number of case switches equal to the number of functions and methods in PHP (including user defined).

或者为了只处理用户输入，在所有脚本的开头初始化一个静态控制器类，1)根据允许的目的白名单验证和存储所有用户提供的输入值;2)删除输入源(即$_SERVER = null)。你可以看出这有一点纳粹主义。

还要注意允许任意内存位置被读写的“中断漏洞”类!

这些影响函数，如trim()， rtrim()， ltrim()，爆炸()，strchr()， strstr()， substr()， chunk_split()， strtok()， addcslashes()， str_repeat()等。这主要(但不完全)是由于该语言的调用时引用传递特性，该特性已经被弃用了10年，但并没有被禁用。

欲了解更多信息，请参阅Stefan Esser在BlackHat USA 2009 Slides Paper上关于中断漏洞和其他底层PHP问题的演讲

本文还展示了如何使用dl()来执行任意系统代码。

我知道move_uploaded_file已经被提到了，但是文件上传通常是非常危险的。仅仅是$_FILES的存在就应该引起一些关注。

可以将PHP代码嵌入到任何类型的文件中。带有文本注释的图像尤其容易受到攻击。如果代码按原样接受在$_FILES数据中找到的扩展名，那么这个问题就特别麻烦。

例如，用户可以上传一个有效的带有嵌入式PHP代码的PNG文件作为“foo.php”。如果脚本特别简单，它实际上可能会将文件复制为“/uploads/foo.php”。如果服务器被配置为允许在用户上传目录中执行脚本(通常情况下，这是一个严重的疏忽)，那么您可以立即运行任何PHP代码。(即使图像保存为。png格式，也有可能通过其他安全漏洞让代码执行。)

一份(非详尽的)上传检查清单:

一定要分析内容，以确保上传的内容是它所声称的类型 将文件保存为一个已知的、安全的文件扩展名，该扩展名永远不会被执行 确保在用户上传目录中禁用PHP(以及任何其他代码执行)

您可以在RIPS /config/sink .php中找到持续更新的敏感接收器(可利用的php函数)及其参数列表，这是一个用于php应用程序漏洞的静态源代码分析器，也可以检测php后门。

这本身并不是一个答案，但这里有一些有趣的事情:

$y = str_replace('z', 'e', 'zxzc');
$y("malicious code");

同样，call_user_func_array()可用于执行模糊化函数。

我特别想将unserialize()添加到这个列表中。长期以来，它一直存在各种漏洞，包括任意代码执行、拒绝服务和内存信息泄漏。永远不应该对用户提供的数据调用它。这些vuls中的许多已经在过去的露水年的发布中被修复，但它仍然保留了一对讨厌的vuls，在目前的写作时间。

要了解其他关于危险php函数/使用的信息，请参阅加固php项目及其建议。还有最近的PHP安全月和2007年的PHP bug月项目

还要注意，按照设计，反序列化对象将导致执行构造函数和析构函数;另一个不调用用户提供的数据的原因。