Composer在生产环境中禁用eval与动态代码执行的硬加固策略-composer-PHP中文网

生产环境必须同时禁用eval、create_function、assert等函数，禁用reflection类，严格限制composer install参数，关闭ffi和opcache jit，并正确设置vendor目录权限。

composer在生产环境中禁用eval与动态代码执行的硬加固策略

生产环境必须禁用 eval 和 create_function，但不能只靠 disable_functions

PHP 8.0+ 已废弃 eval 和 create_function，但它们仍可能通过反射、assert 或第三方扩展间接触发。仅在 php.ini 中写 disable_functions=eval,create_function 不够——assert 在 PHP 8.3 仍支持字符串参数执行代码，这是最常被绕过的入口。

disable_functions 必须包含：eval,create_function,assert,unserialize,pcntl_exec,shell_exec,system,exec,passthru,popen,proc_open
disable_classes 必须包含：ReflectionClass,ReflectionMethod,ReflectionFunction,ReflectionExtension（防止运行时动态构造类或方法）
若项目依赖 var_dump 或 debug_backtrace 做调试，不要禁用它们——它们不执行代码，禁了反而干扰 Laravel Telescope 等监控工具

composer install 阶段就要阻断所有脚本与插件的动态执行

很多攻击链始于 composer install：恶意包的 post-install-cmd 脚本可调用 file_put_contents 写 WebShell，插件能 hook autoloader 注入逻辑。这不是“开发阶段才要管”的事，是部署前必须卡死的环节。

CI/CD 构建命令必须为：composer install --no-scripts --no-plugins --no-dev --prefer-dist --optimize-autoloader
--no-scripts 和 --no-plugins 必须同时出现，缺一不可：--no-plugins 不影响 scripts，--no-scripts 也不禁用插件
本地 composer.json 应显式清空钩子："post-install-cmd": []，避免漏掉参数时仍执行空数组以外的逻辑
验证是否生效：检查部署后 vendor/composer/autoload_plugins.php 是否为空，且日志里没有 Loading plugin 或 Running script

OPcache + 禁用 FFI 是 eval 类攻击的最后防线

即使 disable_functions 全开了，攻击者仍可能通过 FFI 加载恶意 so、或利用 OPcache JIT 缓冲区漏洞执行任意代码。PHP 8.1+ 默认启用 FFI，但它在绝大多数 Web 应用中完全不需要。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

在 php.ini 中强制关闭：ffi.enable=Off（不是 0 或 false，必须是 Off 字符串）
OPcache 需启用两项硬约束：opcache.enable=1 且 opcache.jit=off（JIT 在 PHP 8.2+ 存在已知绕过风险，生产环境应禁用）
如果用了 ProxyManager 等依赖 eval() 的库，改用 FileWriter + 显式 autoload 映射，绝不在生产环境配 EvalLoader——OPcache 不缓存 eval 代码，每次请求都重解析，CPU 拉满还易被拦截

vendor 目录权限设置错误会让所有加固失效

再严的 disable_functions 也防不住 PHP 进程自己往 vendor/ 里写文件。一旦 www-data 对 vendor/composer/ 有写权，攻击者就能覆盖 autoload_static.php 或注入新类映射——这比绕过 eval 禁用简单得多。

vendor/ 目录权限必须是 755（非 555），否则 opendir() 失败，autoload.php 直接报错
所有文件统一设为 644：find vendor/ -type f -exec chmod 644 {} \;
仅放行明确需执行的二进制：chmod +x vendor/bin/* 2>/dev/null || true，其余删掉
关键点：www-data 必须属于 deploy 组，且 vendor/ 所属组为 deploy——否则即使权限对，组读执行位也不生效

真正起作用的不是某一条配置，而是 disable_functions、composer install 参数、OPcache 策略、vendor 权限四者同时生效。漏掉任意一环，攻击者都能找到路径绕过。尤其注意 www-data 的组归属和 vendor/ 的执行位——这两处出错，连 autoload.php 都加载不了，加固就全白做了。