防止PHPINFO被访问的实用方法

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 泄露风险

很多团队把安全检查卡点放在上线后扫描，但更高效的做法是把检测嵌入构建或预发布流程。

• 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() 调用——这类需要代码审计+运行时监控双覆盖。

本篇关于《防止PHPINFO被访问的实用方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！