技术小哥须知——OWASP Top10 列表是否够用引发的思考

本文将主要解读一篇关于讨论 OWASP Top10 与 NVD CWE 列表的有趣论文，并结合笔者的相关经历和思考分享一些经验。

背景

对安全行业的人来说， OWASP Top10 恐怕没有人觉得陌生，这已经是一个众所周知的项目。这个项目已经运行了很多年，在过去的10年当中，这个项目分别在2004年、2007年、2010年、2013年、2017年几乎每三年发布一次更新，每一次发布的 Top10 漏洞列表都是当时最流行的前十个 Web 漏洞。

这个 Top10 列表也因此得到大众的认可，每一次更新也受到了很大的关注。很多 Web 安全的初学者也会选择将这个列表当作一个指导性的学习材料。

几年前，我有幸在公司内部负责过“应用安全”培训工作，课程的受众是公司刚入职的不同层级的开发测试人员（有时也有其他技术岗位的同事出现），他们都来自不同的公司，项目经验以及对安全的理解是水平不一的，可以说很大一部分人（特别是项目经验不够丰富或者没踩过多少坑的人）对安全漏洞的原理或防范知之甚少。很自然的，课程的目标就是让这些开发测试人员写出更安全的代码，提升代码质量。作为讲师，在有限的时间内（培训时长一般在1.5小时左右），讲解的内容要覆盖常见的 Web 漏洞原理、攻击方法以及修复方案，是要花一些心思的。为了更具普适性，我也很自然的选择了 OWASP Top10 作为培训指导大纲，但由于时间有限，我只选择了其中一些在业务开发中经常出现的漏洞。

在经过多次培训并跟踪参与培训的开发测试人员在实际业务项目中开发的代码，我发现有部分人还是“写”出了漏洞，这些漏洞中不仅包括了培训课程已讲解过的，也包括未讲解过的，特别是业务逻辑类的漏洞。因此，我不禁产生两个疑问：

1.应用安全培训是否可以有效帮助开发人员写出安全的代码或者如何提效？

2.OWASP Top10 对开发人员写出安全的代码是否够用？

之前我见过不少人也在讨论第一个问题。确实，培训是否有用很难直接下结论，这其中有很多因素。例如：课程内容、讲解方式、开发人员的水平甚至是培训时间的选择（下午容易犯困）等等。但就我个人的经验来看，如果培训的时候只是单纯的讲解知识点，培训的效果会大打折扣。在经过一些思考和实践后，我有几点建议（不一定适用于你）：

1. 讲解时要有生动的、贴合业务场景的案例，这有助于开发人员理解漏洞。

2. 培训要有实操。推荐使用 OWASP 出品的开源项目——WebGoat，它有很多优点。

3. 授人以鱼不如授人以渔。让开发人员对“黑客技术”感兴趣比传授知识更重要！

4. ……

针对第一个问题，这里不再展开讨论，这并非本文的重点，我可能会在另外一篇文章与读者进行讨论;)。

对于第二个疑问，我没有很好的经验要与你分享。毕竟，安全漏洞的种类实在是太多了，在有限的安全培训时间内更是无法一一讲解。因此，在第一个问题中我给出了一个折中的建议（如果算的话）。一个偶然的机会我看到了一篇文章，该文章的作者从另外一个角度对 OWASP Top10 列表做了分析，最终得出了一些客观的结论。在下面的几个章节中，我将会把这篇论文的大致内容和分析思路做个解读和分享。

如果你有新的想法欢迎在评论区进行讨论。

OWASP Top10 回顾

OWASP Top10 是一个面向开发人员和 Web 应用程序安全性的标准意识文档。它代表了关于 Web 应用程序最关键的安全风险的广泛共识。—— OWASP Top10 官方说明

当前最新的 OWASP Top10 是2017版，相较于 2013版有了一些更改，主要的变化有：

· 合并了 “A4不安全的直接对象引用”和“A7功能级访问控制缺失”，成为“A5:2017 失效的访问控制”

· 去掉了 “A8 CSRF”

· 去掉了 “A10未验证的重定向和转发”

· 新增了 “A4:2017 XML外部实体（XXE）”

· 新增了 “A8:2017-不安全的反序列化”

· 新增了 “A10:2017-不足的日志记录和监控”

如下图所示：

从风险分类来看，OWASP Top10 的分类粒度还是比较粗的，并且 Top10 的结果是根据数据统计和社区投票反馈得出的。按照 OWASP Top10 平均每三年更新一版的节奏，2020版值得期待。目前，官方已经发起了 OWASP Top10 2020 数据分析计划，目的是对 Top10 漏洞和其他未来的研究项目进行分析。

名词解释

除了 OWASP Top10 列表外，和漏洞命名、分类有关的还有 CVE 和 CWE：

· CVE （Common Vulnerabilities & Exposures，通用漏洞和风险）相信大家并不陌生，它是由非盈利的组织 MITRE 公司维护的一个安全漏洞库（http://cve.mitre.org/），并对漏洞名称进行标准化以便能快速能够快速而有效地鉴别、发现和修复软件产品中的漏洞。 MITRE 会定期公布新的漏洞，并更新 CVE 列表，但其对漏洞的分类太过粗糙，不利于漏洞分类的评估工作。

· CWE（Common Weakness Enumeration，通用弱点枚举）是由美国国土安全部国家计算机安全部门资助的软件安全战略性项目，也是由 MITRE 公司维护（http://cwe.mitre.org/）。它更侧重于对漏洞进行分类、定义，CWE 更有利于漏洞分类的评估。

注：在笔者撰写这篇文章期间，CWE 列表发布了 4.0 版本，建议读者查阅其官方页面。

CVE 和 CWE 的关系

CVE 侧重于对某个具体的漏洞进行命名（分配编号）和说明，而 CWE 更侧重于对所有漏洞进行分类。显然，CVE 和 CWE 有着一对多的映射关系。此外，CVE 的 ID 通常会有一个 CWE 编号。

提出问题

在这篇论文中，作者首先提出了 4 个问题，如下：

1.在过去十年里，美国国家漏洞数据库（NVD）中的前十个 CWE 是什么？

2.之所以提出这个问题，是因为在 NVD 中包含了所有披露的安全漏洞的详细记录，并且我们可以从一个宏观的角度确定哪些问题与安全缺陷有关。

3.OWASP Top10 中描述的漏洞对应的 CWE ID 是什么？

4.OWASP Top10 中描述的漏洞对应的 CWE ID 列表是这篇论文最重要的分析结果之一。

5.近十年内，在 NVD 中记录的 Top1 CWE 是什么？这与 OWASP Top10 列表的第一位是否相同？

6.这个问题非常有趣，最终的分析结果也出乎人们的意料。通过分析出的结果，我们可以评估 OWASP Top10 与过去十年中报告的漏洞是否一致。

7.在 NVD 中记录的有 CWE ID 的漏洞有多少出现在了 OWASP Top10 CWE 中？

8.这个问题有助于我们确认 OWASP Top10 列表是否引起了开发人员的关注。因为当人们说起 OWASP 时，只知道这是一个组织，而 Top10 漏洞列表是 OWASP 发起的众多项目之一，尤其是 Top10 漏洞列表只针对 Web 应用程序。

数据准备和分析

在分析数据前，需要采集数据。历史漏洞信息可以在 NVD 官网的数据源页面中找到，但是数据是以 JSON 格式输出的并且近十年的数据并没有一起放在一个文件中，如下图所示：

我们可以使用 Python 脚本将历年的数据逐一爬取，然后将 JSON 格式的数据归一化处理为 csv 格式，然后使用 Pandas 读取数据并将数据框转化为 Series 对象方便后面的处理。整体的数据处理过程如下：

1.数据归一化

2.使用 pandas.io.json 包中的归一化函数将 JSON 对象逐一遍历，并转换为数组。

3.数据处理

4.使用 Pandas 读取数据并将数据框转换为 Series 对象，方便我们读取具体的某一列数据。代码如下图所示。

5.数据提取

6.接下来，提取具有 CWE 的列，然后获取每个漏洞的关联 ID。这里要注意一点，对于任何给定的漏洞，可能会有多个 CWE 编号或ID。代码如下图所示。

7.数据转换

8.最后，我们需要将数据转换成 excel 文件，将所有结果汇总在一起，使用 Excel 内置的透视表手动分析数据。

数据分析结果

通过分析数据得出结果后，我们就可以观察数据反映出的客观事实来回答前面提出的四个问题。

1. 在过去十年里，美国国家漏洞数据库（NVD）中的前十个 CWE 是什么？

1）CWE 119 – 缓冲区溢出

2) CWE 79 – 跨站脚本

3) CWE 20 – 不正确的输入验证

4) CWE 200 – 信息泄露

5) CWE 264 – 权限、特权和访问控制

6) CWE 84 – 网页中错误编码 URI 的方案

7) CWE 310 – 密码问题

8) CWE 125 – 越界读取

9) CWE 399 – 资源管理错误

10) CWE 352 – CSRF

这个列表可以说是这篇论文最重要的贡献，通过对过去10年(2010年至2019年)中软件安全漏洞进行全面的统计和分析，能够让我们对过去十年中的十大安全弱点有一个大致的了解。

2. OWASP Top10 中描述的漏洞对应的 CWE ID 是什么？

由于 OWASP Top10 和 CWE 的分类逻辑不同，所以这个问题的分析结果会比较长，如下：

· a) 类别 A1 注入i) CWE-77 - 命令中使用不正确的特殊元素(“命令注入”)ii) CWE-78 - 操作系统命令中使用不正确的特殊元素(“操作系统命令注入”)iii) CWE-88 - 命令中不正确的参数分隔符(“参数注入”)iv) CWE-89 - SQL命令中使用不正确的特殊元素(“SQL注入”)v) CWE-90 - LDAP 查询中使用不正确的特殊元素(“LDAP注入”)vi) CWE-91 - XML注入(又称 XPath 盲注)vii) CWE-564 - SQL注入:Hibernateviii) CWE-917 - 表达式语言语句中使用不正确的特殊元素(“表达式语言注入”)ix)CWE-943 – 数据查询逻辑中使用不正确的特殊元素

· b) 类别 A2 失效的身份认证i) CWE-287 - 不正确的认证ii) CWE-256 - 无保护的凭证存储iii) CWE-308 - 使用单因素认证iv) CWE-384 - 会话固定v) CWE-522 - 外部方可访问的文件或目录vi) CWE-523 - 不受保护的凭证传输vii) CWE-613 - 会话过期不足viii) CWE-620 - 未经验证的密码更改ix) CWE-640 - 密码恢复机制弱，容易忘记密码

· c) 类别 A3 敏感信息泄漏i) CWE-220 - FTP根目录下的敏感数据ii) CWE-295 - 证书验证不正确iii) CWE-311 - 敏感数据加密缺失iv) CWE-312 - 敏感信息明文存储v) CWE-319 - 敏感信息的明文传输vi) CWE-320 - 密钥管理错误vii) CWE-325 - 缺少所需的加密步骤viii) CWE-326 - 加密强度不足ix) CWE-327 - 使用损坏的或有风险的密码算法x) CWE-328 - 可逆单向哈希xi) CWE-359 - 公开私人资料(“侵犯隐私”)

· d) 类别 A4 XML 外部实体（XXE）i) CWE-611 - 错误地限制XML外部实体引用ii) CWE-776 - DTD 中递归实体引用的错误限制(“XML实体扩展”)

· e) 类别 A5 失效的访问控制i) CWE-22 - 将路径名限制到受限目录的错误限制(“路径遍历”)ii) CWE-284 - 访问控制不当iii) CWE-285 - 不正确的授权iv) CWE-425 - 直接要求(“强制浏览”)v) CWE-639 - 通过用户控制密钥绕过授权

· f) 类别 A6 安全错误配置i) CWE-16 - 配置ii) CWE-209 - 通过错误消息公开信息iii) CWE-548 - 通过目录遍历公开信息

· g) 类别 A7 跨站脚本（XSS）i) CWE-79 - Web 页面生成过程中的错误输入(“跨站脚本”)

· h) 类别 A8 不安全的反序列化i) CWE-502 - 不可信数据的反序列化

· i) 类别 A9 使用含有已知漏洞的组件

· j) 类别 A10 不足的日志记录和监控i) CWE-223 - 遗漏与安全有关的信息ii) CWE-778 - 不足的日志记录

上面的 “类别 A9”特别重要，这个类别指的是使用已知的易受攻击的软件组件。因此，我们不能简单的指向任何一个单一的 CWE ID，因为有 CWE ID 实际上已经是已知的漏洞了，所以它应该指向所有的 CWE 类别。以上列表中的所有 CWE 都对应于不同的类别，严重程度各不相同。

3. 近十年内，在 NVD 中记录的 Top1 CWE 是什么？这与 OWASP Top10 列表的第一位是否相同？

分析可得出 Top1 CWE 是 CWE-119(缓冲区溢出)。显然这与 OWASP Top10 的类别 A1（注入）完全不同。OWASP Top10 的类别 A1 包含的 CWE ID 有：77、78、88、89、90、81、564、917和943，均为注入漏洞。可以从下图中直观的看出此结果：

图：近十年中，NVD 记录的漏洞的 CWE ID Top10

从上图还可以看出，OWASP 真正关注的是 Web 应用程序的安全性，而不是桌面和移动等其他体系架构的应用程序。但是，在后端操作数据的技术堆栈中，也可能出现攻击者绕过浏览器提供的默认安全控制而直接攻击底层应用程序编程接口(API)的情况。例如，假设后端服务器代码中监听了 HTTP 请求，并且存在缓冲区溢出漏洞。那么攻击者可以通过特定的参数来专门构造一个 HTTP GET 请求，从而触发缓冲区溢出漏洞的利用，进而导致严重的安全后果。后端也有可能存在任意代码执行漏洞，同样也可能导致底层系统被攻击。

4. 在 NVD 中记录的有 CWE ID 的漏洞有多少出现在了 OWASP Top10 CWE 中？

这个问题的答案似乎很明显。NVD 中记录的弱点数量要远远大于 OWASP Top10 列出的漏洞，换句话说， OWASP Top10 中列出的漏洞全部都包含在 NVD 中。

图：2010-2019年，出现在 OWASP Top10 列表中的 NVD 已记录的 CWE ID排名。

上图显示了2010至2019年，出现在 OWASP Top10 列表中的 NVD 已记录的 CWE ID。从上图也可以看出，图中的Top10 与 OWASP Top10 也不相同。这是一个有趣的分析结果，因为与过去十年的观察结果相比，OWASP Top10 列表也在发生变化。也许，我们需要编译出一个更好的列表，可以更好地满足开发人员的需求。这样他们就能更清楚地意识到其他工程师最常犯的一些错误。

结论

这篇论文的研究并没有考虑软件架构的历史变迁。以前，会有很多基于桌面的应用程序，而现在我们正在向移动、Web和基于云的应用程序迁移。如果我们能够控制不同软件架构的整体变化，那么也许我们的分析工作会得到不同的结果。任何软件都有其弱点，所以这篇论文更多的是一篇观察和分析类型的文章，而不是一篇介绍某种工具或者给出某个定论的文章。

另外，OWASP 只考虑 Web 应用程序中的漏洞，并且我们只将其与 NVD 中记录的漏洞做了比较。尽管如此，在逻辑上和概念上，这两个 Top-N 列表都有很多重叠的地方，因此值得人们继续探索和理解。

笔者的一点思考

正如文章作者所说的，“这篇论文更多的是一篇观察和分析类型的文章，而不是一篇介绍某种工具或者给出某个定论的文章。”，通过客观的数据分析可以得出，无论是 OWASP Top10 还是 CWE Top25 ，都各有其特点，比较这两个或其他的 Top-N 漏洞列表，很难一评高下。如果你负责的业务只需考虑 Web 应用程序的安全性，那么选择 OWASP Top10 作为学习研究、培训赋能的资料也完全够用。但是站在一个更高的层次来说，CWE Top25 会更加全面，其涵盖了很多非 Web 应用程序的弱点，这有助于开发人员在编码过程中，考虑后端服务、底层服务的弱点，从而能在一定程度上保证整个调用链路的安全性。

参考资料

· 论文原文：https://arxiv.org/abs/2002.11269

· CWE 官网：http://cwe.mitre.org/index.html

· CVE 官网：http://cve.mitre.org/

· OWASP Top10 中文版：http://www.owasp.org.cn/owasp-project/OWASPTop102017v1.3.pdf

· OWASP Top10 项目官网：https://owasp.org/www-project-top-ten/

· CWE 4.0 更新说明：https://cwe.mitre.org/data/