PHP框架审计必须检查自动加载机制，否则可能因恶意类名触发任意文件包含或路径遍历导致RCE；需确认是否启用Composer自动加载器，检查vendor/autoload.php是否由Composer生成，并审计composer.json中PSR-4等配置是否存在绝对路径或用户输入拼接等高危情况。
PHP框架审计中必须检查自动加载机制是否被恶意利用，否则攻击者可通过构造特定类名触发任意文件包含或路径遍历，导致远程代码执行。这一步不能跳过，因为多数框架默认启用自动加载，而开发者常忽略其安全边界。
确认项目是否启用自动加载及类型
运行composer show --installed | grep autoload，观察输出中是否含composer/composer或symfony/dependency-injection等依赖——有即说明使用Composer自动加载器；若无，则需检查vendor/autoload.php是否存在并被require调用。
打开vendor/autoload.php，查看头部注释是否含Generated by Composer字样。不是则为手写加载器，需进入下一步人工审计。
检查composer.json中"autoload"或"autoload-dev"字段是否存在"psr-4"、"psr-0"、"classmap"或"files"配置项。存在任一即启用自动加载。
立即学习“PHP免费学习笔记（深入）”；
审计PSR-4映射路径是否可控
方法一：检查composer.json中的autoload.psr-4键值对
重点看value是否为绝对路径（如"/var/www/app/src/"）或含用户输入拼接（如"src/{$env}/"）。【绝对路径或变量拼接路径属于高危配置，会绕过命名空间隔离】
方法二：提取所有注册的PSR-4前缀与目录映射
执行php -r "include 'vendor/autoload.php'; var_dump(composerutoloader::getPrefixesPsr4());"，输出类似["App\"]=>["src/"]结构。若value目录可被Web直接访问（如src/在public/同级），且未禁用PHP解析，则存在任意PHP文件执行风险。
方法三：验证命名空间是否被意外暴露
创建测试文件test.php，内容为<?php new AppNonExistentClass();，访问该文件。若报错信息含require(/var/www/html/src/NonExistentClass.php)，说明路径完全暴露——攻击者可据此爆破目录结构。
排查手写spl_autoload_register加载器漏洞
第一步：全局搜索spl_autoload_register调用位置
在项目根目录执行grep -rn "spl_autoload_register" --include="*.php" .，重点关注非vendor/目录下的结果，尤其是bootstrap.php、init.php或core/Loader.php。
第二步：检查回调函数内是否对类名做过滤
找到注册的匿名函数或方法，确认是否包含str_replace、preg_replace或basename等路径净化操作。若直接拼接$class . '.php'且未校验..或/，则存在路径遍历漏洞。
第三步：验证是否允许加载非预期后缀文件
手动构造类名../../../../etc/passwd，触发自动加载逻辑（如new ../../../../etc/passwd();）。若服务器返回passwd内容或500错误但无日志拦截，则说明加载器未限制文件扩展名或路径合法性。
这一步操作起来很简单，直接把测试代码写进临时PHP文件里执行就行。
检测vendor/autoload.php是否可被Web直接访问
在浏览器中访问http://your-domain.com/vendor/autoload.php。若返回404以外的状态码（尤其是200或500），【立即中断审计并修复Web服务器配置】。
检查Nginx配置中是否存在location ^~ /vendor/ { return 403; }；Apache中是否配置RedirectMatch 403 ^/vendor(/|$)。未配置即视为漏洞，因该文件可能泄漏vendor/composer/installed.json中的完整依赖树和版本号。
运行curl -I http://localhost/vendor/autoload.php 2>/dev/null | head -n 1，返回HTTP/1.1 403 Forbidden才算安全。
