PHP框架审计总结需按真实利用路径归类漏洞，剔除与框架无关的通用Web漏洞；按核心层、扩展层、集成层划分三类，结合版本锚定、配置依赖、补丁验证动态判定风险等级；输出采用表格形式，含漏洞类型｜触发条件｜影响版本｜实测状态｜风险等级｜修复建议六项，实测状态须写明具体验证动作，风险等级统一为低｜中｜高｜严重四级。
写PHP框架审计总结时，需把漏洞按真实利用路径归类，不能只堆砌CVE编号；风险等级必须结合框架版本、默认配置、是否启用危险组件来动态判断，脱离上下文标“高危”会误导修复优先级。
梳理漏洞分类体系
第一步：剔除与框架无关的通用Web漏洞。例如某次审计发现的SQL注入，实际源于开发者未过滤$_GET参数，而非Laravel Eloquent默认行为——这类问题不计入框架自身缺陷。
第二步：按触发层级划分三类漏洞。核心层（如Symfony HttpFoundation解析逻辑）、扩展层（如ThinkPHP的模板引擎沙箱逃逸）、集成层（如CodeIgniter与第三方JWT库组合使用导致签名绕过）。
第三步：对每类漏洞标注典型PoC特征。比如“反序列化链起点在vendor/autoload.php自动加载机制中”属于核心层，“模板中{php}标签未被禁用”属于扩展层，“config.php硬编码密钥+JWT库未校验alg字段”属于集成层。
立即学习“PHP免费学习笔记（深入）”；
确定风险等级评估依据
方法一：版本锚定法。查框架官方安全公告，确认漏洞是否存在于当前生产环境版本。若项目用Laravel 8.72，而CVE-2022-3513仅影响8.83+，则【该漏洞实际不可利用】，直接标记为“不适用”。
方法二：配置依赖法。某些漏洞需开启特定选项才生效，如Yii2的debug模式开启时暴露敏感信息。检查phpinfo()和.env文件，确认APP_DEBUG=true后才将此类漏洞定为中危及以上。
方法三：补丁验证法。下载对应版本的vendor包，用diff工具比对官方修复提交。若项目中vendor/yiisoft/yii2/web/Request.php第421行仍存在未过滤的getHeaders()调用，则说明补丁未生效，风险等级上调一级。
输出审计总结正文结构
直接以表格形式呈现，表头为：漏洞类型｜触发条件｜影响版本｜实测状态｜风险等级｜修复建议。
“实测状态”栏必须填写具体验证动作，例如：“本地复现成功，构造POST /index.php?_method=__construct绕过CSRF校验”或“尝试利用CVE-2021-29472，返回404，确认已升级至laravel/framework v8.83.3”。
风险等级统一用“低｜中｜高｜严重”四级，不加括号说明。同一漏洞在不同部署环境下可填不同等级，例如“反序列化POP链”在Docker容器中因disable_functions限制标记为中，在物理机上标记为严重。
