phpinfo() 不可公开访问，因其会暴露php配置、扩展、环境变量、服务器信息等敏感数据，助攻击者精准利用漏洞；应删除或重命名相关文件，并通过web服务器配置禁止访问，辅以ci/cd自动化检测与waf兜底防护。
为什么 phpinfo() 不能放在生产环境公开访问
因为 phpinfo() 会直接暴露服务器全部 PHP 配置、扩展列表、环境变量、$_SERVER 内容、PHP 版本、Web 服务器类型（如 Apache/Nginx）、已加载的 ini 文件路径，甚至可能包含数据库连接串、密钥所在目录等敏感线索。攻击者拿到这些信息后，能精准选择漏洞利用路径（比如针对特定版本的 gd 扩展或 opcache 配置缺陷发起攻击）。
删除或重命名 phpinfo.php 文件是最直接有效的防护
绝大多数误公开都源于开发者测试后忘记清理临时文件。只要没有主动调用，phpinfo() 函数本身不会自动执行——它只在被写入并被执行的 PHP 脚本中才起作用。
- 检查 Web 根目录及子目录下是否存在
phpinfo.php、info.php、test.php等常见命名文件 - 使用命令快速扫描：
find /var/www -name "*phpinfo*" -o -name "info.php" -o -name "test.php" | xargs grep -l "phpinfo()" 2>/dev/null
- 确认无业务依赖后，直接
rm删除；若需保留用于内部调试，改名为带随机后缀且不对外索引的名称，例如phpinfo_8a3f2d.php，并确保该文件不在任何公开链接或 sitemap 中出现
通过 Web 服务器配置禁止访问所有含 phpinfo 的脚本
仅靠人工清理不可靠，尤其在多人协作或 CI/CD 自动部署场景下。应叠加服务器层访问控制，做到“即使误传也打不开”。
- Apache：在
.htaccess或虚拟主机配置中添加<FilesMatch "(phpinfo|info|test)\.php$"> Require all denied </FilesMatch> - Nginx：在 server 块中加入
location ~* /(phpinfo|info|test)\.php$ { deny all; }注意：该规则需放在location ~ \.php$ { ... }主处理块之前，否则会被覆盖 - 不要依赖
php_flag display_errors off或禁用函数（disable_functions = phpinfo），因为前者不影响已存在的脚本执行，后者可能被绕过且影响调试类工具
上线前自动化检查 phpinfo 泄露风险
很多团队把安全检查卡点放在上线后扫描，但更高效的做法是把检测嵌入构建或预发布流程。
立即学习“PHP免费学习笔记（深入）”；
- CI 阶段用
grep -r "phpinfo(" ./src/ --include="*.php"检查源码是否残留调用（注意排除 vendor） - 部署后自动发起探测请求：
curl -s -o /dev/null -w "%{http_code}" http://your-site.com/phpinfo.php若返回 200，即触发告警或阻断发布 - 配合 WAF 规则（如 ModSecurity）拦截 URL 中含
phpinfo且响应体含PHP Version字样的请求，作为兜底防御
真正难防的不是明面上的 phpinfo.php，而是那些被封装在调试接口、未文档化的管理路由、或错误页面中意外输出的 phpinfo() 调用——这类需要代码审计+运行时监控双覆盖。
