OWASP 与真实世界的漏洞

威胁建模问的是：在动手开发之前，可能出什么问题？

而 OWASP 帮你识别的是：在正在运行的应用里，已经出了什么问题。

一份漏洞报告可能会这样写：

一个已登录的客户，可以修改 /orders/123 中的 id，读取到别人的订单。

这是一个真实的漏洞，但它也有一个通用的名字：访问控制失效（broken access control）。在 OWASP Top 10 里，这是 A01。

OWASP 是什么

OWASP 是 Open Worldwide Application Security Project（开放全球应用安全项目），一个发布免费应用安全指南的非营利社区。

OWASP 最广为人知的项目是 OWASP Top 10。这是一份罗列常见且严重的 Web 应用安全风险类别的清单。

把它当成一张地图，而不是一份检查清单。

目前发布的最新版本是 2025 年版

OWASP 表示，目前正式发布的最新版本是 OWASP Top 10 2025。

下面的分类名称和编号都采用这个版本。

这份清单给了开发者一套共同的语言。团队不用再说"这个应用让用户看到了他们不该看到的记录"，而可以直接说"这是访问控制失效"。

简短的名字并不能修复漏洞，但它能帮人更快找到该讨论的那件事。

JunoOWASP 是什么 OWASP 就像一张记录常见应用安全隐患的共享地图。

Top 10 并不能证明一个应用是安全的。它帮你识别的是，开发者在真实 Web 应用中反复踩到的那些坑。

JunoOWASP 是什么 把 Top 10 当作评审和漏洞报告里的通用词汇来用。"A01 访问控制失效"比重新解释一遍"用户能访问超出自己权限的数据或操作"要简短得多。

真正的好处在于定位。一旦分类确定了，你就知道该查哪块代码、该写哪些测试、后面手册里的哪一章会深入讲解。

JunoOWASP 是什么 OWASP 始于 2001 年，那时"Web 应用安全"这个领域还在争取自己的一席之地。Top 10 之所以流行，是因为把问题装进十个筐里，比列出一整面墙的具体弱点更容易带进会议室讨论。

但这种流行也是个陷阱。"我们覆盖了 Top 10"并不能证明系统安全，它只能说明你检查过那些共性问题。

真正棘手的失误，往往还是藏在你产品特有的那些决策里——没有哪份全球通用的清单，会知道你和现实达成的那些古怪的妥协。

2025 版分类

你不需要死记这份清单。把每个分类当作一个可以拿来审视代码的问题就行。

代码	分类	开发者该问的问题
A01	访问控制失效 (Broken Access Control)	有没有人能访问到不该访问的数据或操作？
A02	安全配置错误 (Security Misconfiguration)	有没有不安全的设置被带上线？
A03	软件供应链失效 (Software Supply Chain Failures)	你能信任所用的包、工具和构建流程吗？
A04	加密机制失效 (Cryptographic Failures)	私密数据在存储或传输时是否受到保护？
A05	注入 (Injection)	用户输入的文本能不能变成一条指令？
A06	不安全的设计 (Insecure Design)	这个不安全的选择是不是在写代码之前就已经定下了？
A07	身份验证失效 (Authentication Failures)	应用能不能可靠地判断出对方是谁？
A08	软件或数据完整性失效 (Software or Data Integrity Failures)	代码或数据在到达你这里之前有没有被篡改？
A09	安全日志和告警失效 (Security Logging and Alerting Failures)	有没有人会注意到这次攻击？
A10	异常状况处理不当 (Mishandling of Exceptional Conditions)	出错时，应用会不会因此变得不安全？

顺序其实不重要，重要的是养成习惯。找一个真实的漏洞，说出它的分类，再用大白话解释它造成的影响。

对于订单 id 这个漏洞，分类是 A01 访问控制失效。影响是：任何已登录的客户，都能读取到其他客户的订单历史和收货地址。

OWASP 给漏洞起了个名字，但影响还得由你的报告来说清楚。

Juno2025 版分类 每一个 OWASP 分类，都是一个装了许多小漏洞的筐。

先从最朴素的问题问起：有没有人能读到不该读的东西？能改动不该改的东西？能让应用停止响应？想清楚危害之后，分类名称自然就水到渠成了。

Juno2025 版分类 先说出分类，再写出用户能感受到的后果。"A01"很有用，但真正能帮团队排优先级的，是"任何已登录的客户都能读到其他客户的地址"这句话。

这样才能避免 OWASP 变成一种贴标签游戏。分类负责把工作导向正确的方向，而影响说明的是这项工作为什么重要。

Juno2025 版分类 2025 版清单之所以变化，是因为软件本身变了。供应链失效被纳入了主榜单，异常状况处理独立成了一个分类，服务端请求伪造（SSRF）则并入了访问控制失效。

要仔细看待不同版本之间的排名变化。一个分类排名上升，可能是因为它的定义变宽了，可能是因为贡献者换了人，也可能是因为工具变得更擅长发现它了。排名是一个信号，不是整个行业的天气预报——有用，没错，但也谈不上无所不知，而这大概也是好事。

STRIDE 之后的 OWASP

STRIDE 和 OWASP 在不同的时机各有用处。

工具	最佳使用时机	要问的问题
STRIDE	设计之前和设计过程中	可能出什么问题？
OWASP Top 10	评审、测试和分诊阶段	这是哪一类漏洞？

在规划会议上，STRIDE 能帮你发现 QuickBite 需要把价格计算放到服务端完成。

而在一份真实的漏洞报告里，OWASP 能帮你指出：由浏览器控制的价格是一个完整性问题，具体属于注入、访问控制还是不安全设计，取决于它的实现方式。

这两个工具是配合使用的：

1. STRIDE 预测可能出现的失效。
2. 应用被开发和测试。
3. OWASP 帮你为出现的漏洞命名。
4. 漏洞分诊把发现转化为优先级和下一步行动。

JunoSTRIDE 之后的 OWASP STRIDE 用来在功能上线之前问"可能出什么问题"。OWASP 用来在问题真的出现之后，识别你面对的是哪一类漏洞。

你不需要二选一，它们回答的是不同的问题。

JunoSTRIDE 之后的 OWASP 把 STRIDE 用在规划阶段，把 OWASP 用在评审或分诊阶段。这样就有了一条清晰的时间线：预测、开发、识别、排优先级。

如果一个发现只贴了个 OWASP 标签，什么都没有，那就去要复现步骤和影响说明。标签只是一个指向，不是完整的报告。

JunoSTRIDE 之后的 OWASP STRIDE 是设计层面的压力，OWASP 是识别层面的压力，分诊则是交付层面的压力。把它们混在一起，团队就容易写出读起来像漏洞报告的威胁模型，以及读起来像星座运势的漏洞报告。

让这几件事各归其位。代码写出来之前，问"可能出什么问题"；漏洞出现之后，说清楚它属于哪一类、证明这个行为确实存在、说明造成的危害。然后再决定接下来怎么做——别让会议变成大家一起念叨各自焦虑的读书会。

动手试试

这里有五个来自真实待办事项列表的漏洞。为每一个说出对应的 OWASP 2025 分类，再用非工程师也能听懂的一句话写出它造成的影响。

1. 一个已登录的客户修改了 /orders/1042 中的 id，看到了另一个客户的收货地址。
2. 管理后台上线时，默认密码没有被修改。
3. 一个搜索框把用户输入的文本原样拼进了数据库查询语句。
4. 登录失败从来没有被记录下来。
5. 上周有一个依赖包被更新过，而更新它的维护者账号早已被人接管。

对照一下你的答案

#	分类	用大白话说明影响
1	A01 访问控制失效	任何已登录的客户都能读取到其他客户的订单历史和收货地址
2	A02 安全配置错误	任何知道默认密码的人都能获得完整的管理权限
3	A05 注入	访问者可以让数据库执行应用本不打算执行的命令，从而读取或删除数据
4	A09 安全日志和告警失效	有人可以无限次尝试猜密码，而永远不会有人知道这件事发生过
5	A03 软件供应链失效	你没有写过、也从没审查过的代码，正在你的应用里运行

第 4 项是最容易引起争议的一个，因为表面上什么都没坏。但这正是这个分类想说明的问题：真正的失效在于这次攻击不留任何痕迹，导致其他所有的防护措施都失去了被察觉的机会。

注意"影响"这一栏从来没有提到分类名称，这是有意为之，也是值得你记住的习惯：分类负责把工作导向正确的团队，而旁边那句话，才是让这项工作被排上优先级的关键。

接下来去哪里

OWASP 帮你给常见的真实漏洞起了名字。下一章漏洞分诊会讲解，如何把这样一个漏洞变成一份团队可以据此行动的报告。