我正在构建一个Web应用程序，我担心安全性。
这是一种进行"php 注入"的方法，就像进行"SQL 注入"一样？这意味着客户端可以发送一些将在服务器上执行的php代码。
在我们不使用"eval"函数之前，我想说"不"，因为当我们得到一个 $_GET 和 $_POST 的值时，所有数据都被视为简单的字符串......但也许我没有看到明显的攻击。
一般来说，除非你用可能解析和执行PHP的东西来评估它。您已经提到了 eval，但还有其他具有类似 eval 属性的函数（例如 preg_replace，如果攻击者设法注入/e修饰符）或以其他方式允许不需要的访问级别（例如 system() ）。
此外，如果攻击者可以上传文件并将其解释为 PHP，他就可以运行 PHP 代码。 nginx很容易被错误配置，允许攻击者在图像文件中执行PHP代码。让您的网站include()他的代码也是如此 - 可能是通过用他的上传覆盖您的文件，或者更改include()参数以指向远程站点（如果在 php.ini 中未禁用）。
多种方式进行"PHP 注入"。 eval就是其中之一。 shell_exec和相关功能也是一种风险（始终使用escapeshellarg！但共同的主题是将用户输入放在可以执行的地方。SQL注入就是这种情况，其中查询是包含用户输入的字符串，然后在MySQL服务器上执行。
一个稍微晦涩的例子是文件上传。如果您允许将文件上传到您的服务器，请不要允许不受限制地访问它们！有人可以上传一个PHP文件，然后访问它并完全控制您的网站，所以......是的，上传时要小心！
如果PHP脚本"使用来自上游组件的外部影响输入构造全部或部分代码段，但它没有中和或错误地中和可能修改预期代码段的语法或行为的特殊元素"[1]，则可以称之为PHP注入。
因此，对于作为处理器的 PHP 来说，任何参数被直接或间接解释为 PHP 的函数都可能容易被 PHP 注入。这显然包括eval函数，但也包括像create_function这样的函数，以及带有PREG_REPLACE_EVAL修饰符的preg_replace。
此外，这还包括生成 PHP 代码的例程，以便在应用程序设置期间写入配置文件等文件。或者通过php -r …执行PHP的例程，即使通过escapeshellarg转义。
查看观察到的CWE-94示例：代码生成控制不当（"代码注入"）。