4、漏洞分类与定级：分类标准、定级方法与实操案例
漏洞挖到了，然后呢？
很多人觉得，写个报告扔给厂商就完事了。但在我经手的几十个漏洞披露项目里，分类和定级才是真正决定漏洞命运的关键一步。分错了类，厂商可能看不懂；定错了级，要么被忽视，要么引发过度恐慌。
这一节，我们就来聊聊怎么给漏洞“贴标签”和“打分”。
4.1 漏洞分类标准：CWE 到底怎么用？
CWE，全称 Common Weakness Enumeration，通用弱点枚举。说白了，它就是一本“漏洞字典”。
我个人习惯，拿到一个漏洞后，第一件事不是看危害，而是先翻 CWE。为什么？因为只有分对了类，后续的修复和防护才有针对性。
核心原则： 分类不是目的，可追溯才是。CWE 编号能让全球的安全工程师在同一语境下沟通。
4.1.1 常见的 CWE 分类（我常用的几个）
CWE 有几百种分类，但日常披露中，80% 的漏洞集中在以下几类。我列个表，方便你对照：
| CWE 编号 | 名称 | 典型场景 |
|---|---|---|
| CWE-79 | 跨站脚本 (XSS) | 输入框未过滤，反射型/存储型 |
| CWE-89 | SQL 注入 | 拼接查询字符串，未使用参数化查询 |
| CWE-200 | 信息泄露 | 错误堆栈暴露、敏感文件可访问 |
| CWE-287 | 认证绕过 | 弱密码、会话固定、令牌可预测 |
| CWE-434 | 文件上传漏洞 | 未限制上传类型，可上传 Webshell |
| CWE-787 | 越界写入 | 缓冲区溢出，内存损坏 |
我的小技巧： 如果你不确定该选哪个 CWE，去 cwe.mitre.org 搜关键词。比如“upload”，它会列出所有相关的子分类。别自己瞎编编号，合规审计时会出大问题。
4.1.2 分类实操：一个真实案例
我记得有一次，团队发现了一个“用户能查看他人订单”的漏洞。乍一看，像是越权访问。但仔细分析后，我发现问题出在 API 接口没有校验用户身份，直接返回了所有订单数据。
嗯，这里要注意：表象是越权，根因是认证缺失。最终我们把它归到了 CWE-287（认证绕过），而不是 CWE-862（缺少授权）。
为什么？因为修复方案完全不同。认证绕过要改登录逻辑，缺少授权要改权限校验。分错了类，开发同学会修错方向。
4.2 漏洞严重性定级：CVSS 到底怎么算？
分类搞定了，接下来就是定级。行业里最通用的就是 CVSS，通用漏洞评分系统。
说实话，CVSS 3.1 的公式挺复杂的。但你不必背公式，只要理解它的三个核心维度就行：
- 基础指标（Base Metrics）： 漏洞本身的固有属性，比如攻击路径、攻击复杂度、权限要求。
- 时间指标（Temporal Metrics）： 随时间变化的因素，比如是否有公开的利用代码、是否有官方补丁。
- 环境指标（Environmental Metrics）： 针对特定环境的定制化评分，比如你的系统是否暴露在公网。
避坑指南： 我曾经见过有人只算基础分，然后直接报给客户。结果客户说“我们内网环境，攻击路径是网络，不是邻接”，评分直接降了 2 分。记住：对外披露时，一定要注明是哪个维度的评分，否则容易引发争议。
4.2.1 CVSS 评分速查表
为了方便你快速定级，我整理了一个简化版对照表。实际计算建议用官方计算器，但这个表能帮你快速判断区间：
| 严重性等级 | CVSS 分数范围 | 典型特征 |
|---|---|---|
| 无 | 0.0 | 无风险 |
| 低 | 0.1 - 3.9 | 需要特殊条件，影响极小 |
| 中 | 4.0 - 6.9 | 有一定影响，但需要用户交互或特殊权限 |
| 高 | 7.0 - 8.9 | 可直接利用，影响机密性/完整性/可用性 |
| 严重 | 9.0 - 10.0 | 远程无限制利用，完全沦陷 |
我的习惯： 对于“严重”级别的漏洞，我会在报告里额外加一段“业务影响分析”。因为 10 分和 9 分虽然都是严重，但一个是 RCE，一个是信息泄露，厂商的响应优先级完全不同。
4.3 定级实操案例：从发现到定级
光说不练假把式。我们拿一个真实场景走一遍流程。
4.3.1 案例背景
某电商平台的搜索接口存在 SQL 注入。攻击者无需登录，直接在搜索框输入 ' OR 1=1 -- 就能返回所有商品数据，包括隐藏的下架商品。
4.3.2 分类步骤
- 确定根因： 输入未过滤，直接拼接 SQL 语句。
- 匹配 CWE： 查 CWE 字典，对应 CWE-89（SQL 注入）。
- 确认子类： 是“基于布尔的盲注”还是“报错注入”？这里是直接返回数据，属于“显式注入”。
4.3.3 定级步骤
打开 CVSS 3.1 计算器，逐项填写：
- 攻击向量（AV）： 网络（N），因为通过公网 HTTP 请求即可触发。
- 攻击复杂度（AC）： 低（L），不需要特殊条件。
- 权限要求（PR）： 无（N），无需登录。
- 用户交互（UI）： 无（N），自动触发。
- 影响（C/I/A）： 机密性（高）、完整性（高）、可用性（低）。
最终基础分：9.8（严重）。
关键点： 为什么可用性只给了“低”？因为 SQL 注入主要影响数据读取和篡改，不会直接导致服务宕机。但如果注入语句是 DROP TABLE，那可用性就要改成“高”了。这就是细节决定分数。
4.4 知识体系总览：一张图看懂分类与定级
下面这张图，是我自己总结的漏洞分类与定级流程。你写报告时，可以照着这个逻辑走：
4.5 写在最后：分类与定级的“潜规则”
你可能觉得，分类和定级都是技术活，按标准来就行。但我在实际项目中遇到过不少“潜规则”：
- 厂商偏好： 有些厂商对“信息泄露”不敏感，但对“远程代码执行”极度重视。同样的漏洞，换个分类，响应速度天差地别。
- 合规要求： 某些行业（如金融、医疗）对 CVSS 7.0 以上的漏洞有强制披露时限。定级低了，可能违反合规要求。
- 争议处理： 如果厂商对你的定级有异议，别急着争。拿出 CVSS 计算器的截图，逐项解释你的评分依据。我遇到过好几次，厂商看完截图后主动认错。
最后提醒一句： 分类和定级不是终点，而是沟通的起点。你的报告写得再漂亮，如果分类错了、定级偏了，整个披露流程都会跑偏。所以，每次提交前，多问自己一句：这个分类真的准确吗？这个评分经得起推敲吗？