php框架审计需聚焦真实攻击面：一、访问/config/database.php等路径，200响应含凭证即高危；二、检查nginx/apache是否禁用.env等扩展名访问；三、curl -i确认敏感文件不返回text/plain；四、验证环境变量加载逻辑是否绕过错误处理；五、grep硬编码密码、debug=true及固化加密密钥；六、核查日志路径是否位于web根目录下可下载。
在PHP框架审计中快速识别配置文件泄露、硬编码凭证和权限错误，需要一份聚焦真实攻击面的检查清单，而不是泛泛而谈的“注意安全”。
确认配置文件是否被Web服务器直接可访问
第一步：访问常见配置路径，如 /config/database.php、/app/config/app.php、/env、/.env、/config.php，观察HTTP响应状态码与返回内容。若返回200且含数据库账号或密钥，立即标记为高危。
第二步：检查Web服务器配置，确认Apache的 .htaccess 或 Nginx 的 location 块是否显式禁止了对 config/、.env、*.php.bak 等路径的访问。Nginx中遗漏 location ~ \.(env|ini|log|conf|yml|yaml|xml|bak|swp)$ { deny all; } 是常见疏漏。
第三步：用 curl -I 检查敏感文件是否返回了意外的 Content-Type（如 text/plain），这说明服务器未正确处理扩展名，【.env 文件即使无执行权限，以纯文本返回也等同于完全泄露】。
检查环境变量加载逻辑是否绕过安全约束
方法一：查看框架启动入口（如 Laravel 的 public/index.php 或 Symfony 的 public/index.php），定位 Dotenv::load() 或 $_ENV 读取位置。若该调用发生在 error_reporting(0) 或 @include 之后，可能导致加载失败却无日志，配置回退到不安全默认值。
方法二：搜索代码中是否存在 getenv('DB_PASSWORD') 但未校验返回值是否为空——框架常默认使用空字符串连接数据库，结果连上的是无需密码的本地实例。
方法三：检查是否调用 putenv() 动态写入环境变量。这种写法在 CLI 模式下有效，但在 FPM 进程复用场景中会导致变量污染，【一次请求注入的 putenv('APP_DEBUG=true') 可能影响后续数十个用户请求】。
定位硬编码凭证与调试开关
在 config/ 目录下递归 grep -r 'password\|secret\|key\|debug\|dump' *.php *.yml *.env --exclude-dir=vendor。重点关注 config/database.php 中的 'password' => 'root' 和 config/app.php 中的 'debug' => true。
发现 'cipher' => 'AES-128-CBC' 时，必须同步检查 key 是否为 env('APP_KEY') —— 若此处写死为 base64:xxxxxx，则加密密钥已固化，无法通过环境变量轮换。
遇到 config/logging.php 中 handler 设为 'single' 且 path 指向 /var/www/html/storage/logs/laravel.log，要立刻验证该路径是否在 Web 根目录下可被直接下载。很多审计员只看配置项，忽略物理路径暴露风险。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
