disable_functions 对 ThinkPHP 几乎无效，因其不依赖 exec 等函数运行，且攻击者可通过反序列化、模板渲染、路由解析等绕过；真正风险在于参数可控性、模板引擎滥用、runtime 目录权限过大及用户输入未过滤。
为什么 disable_functions 对 ThinkPHP 几乎无效
ThinkPHP 本身不依赖 exec、system、shell_exec 这类函数运行，禁用它们不会影响框架功能，但也不能真正防住利用——因为攻击者常通过反序列化、模板渲染或路由解析等路径绕过函数级限制。真正的风险点不在“用了什么函数”，而在“谁控制了函数的参数”。
-
disable_functions只拦截 PHP 内置函数调用，对eval()、assert()（在 PHP 7.2+ 默认启用）或动态类加载完全无感 - ThinkPHP 5.1+ 默认开启模板引擎编译缓存，若攻击者能写入
runtime/view/目录，可直接植入恶意 PHP 代码，绕过所有函数禁用 - 常见误操作：在 php.ini 中禁用
file_put_contents，结果导致 ThinkPHP 日志写入失败、缓存无法生成，反而暴露错误路径
ThinkPHP 模板层才是高危入口，不是 system()
ThinkPHP 的 think\template\driver\File 和 {:function()} 语法允许在模板中执行任意 PHP 表达式，一旦模板内容可控（如用户提交的页面标题、富文本字段未过滤就进模板），eval 就在后台静默触发。
- 危险写法示例：
{:system('id')}或{:call_user_func('phpinfo')}—— 只要模板被用户间接影响，就可能执行 - ThinkPHP 6.x 默认关闭模板引擎的
tpl_deny_func配置，需手动在config/template.php中显式添加：'tpl_deny_func' => ['exec','shell_exec','system','passthru','popen','proc_open'] - 更稳妥做法：禁用模板中的函数调用语法，把
'tpl_begin' => '{'改成非 PHP 兼容符号（如'tpl_begin' => '{@'），并确保所有模板变量都经htmlspecialchars输出
Runtime 目录权限比禁用函数更重要
ThinkPHP 的 runtime/ 目录是运行时缓存、日志、模板编译的落盘位置。如果 Web 进程（如 www-data）对该目录有写+执行权限，攻击者上传一句话木马后，只需触发一次模板编译，就能让恶意代码落地为可访问的 PHP 文件。
- 典型错误配置：
chmod -R 777 runtime/—— 这等于给攻击者配了把万能钥匙 - 正确权限（Linux）：
chown -R www-data:www-data runtime/ && chmod -R 755 runtime/ && find runtime/ -type f -exec chmod 644 {} \; - 额外加固：在 Nginx/Apache 配置中禁止直接访问
runtime/下的 PHP 文件，例如 Nginx 中加location ~ ^/runtime/.*\.php$ { return 403; }
别碰 assert() 和 call_user_func_array() 的参数
ThinkPHP 路由调度、中间件执行、Hook 回调大量使用 call_user_func_array；而部分老版本扩展（如某些验证码、支付 SDK）会用 assert($str) 动态执行字符串。这两处若参数来自用户输入，禁多少函数都没用。
立即学习“PHP免费学习笔记（深入）”；
- 检查项目中所有
assert(调用，确保参数是硬编码字符串或经过白名单校验的常量，绝不能是$_GET['x']或数据库读取的字段 - 排查
think\Container::invokeMethod、think\facade\Route::miss等调用链，确认回调方法名是否被用户控制（比如 URL 中传?callback=system） - PHP 8.1+ 已废弃
assert()的字符串执行模式，升级 PHP 版本是最省事的加固方式之一
真正卡住攻击链的地方，从来不是“哪个函数被禁了”，而是“哪个变量没过滤”和“哪个目录多给了执行权”。ThinkPHP 的安全水位，取决于你对输入边界的把控，而不是 php.ini 里那一行 disable_functions。
