3、威胁建模入门：常见威胁类型（STRIDE）、威胁来源分析、威胁库的使用
威胁建模，说白了就是在攻击者动手之前，先替他们想好怎么搞破坏。我刚开始做安全那会儿，总觉得这是“纸上谈兵”，直到有一次项目上线前一天，被白帽挖出一个数据泄露漏洞……嗯，从那以后，我再也不敢跳过威胁建模了。
这一章，我们聚焦三个核心问题：威胁长什么样？从哪来？怎么查？
3.1 STRIDE：六种最常见的威胁类型
STRIDE 是微软提出的一套威胁分类模型。我个人习惯把它当作“威胁检查清单”——每次画完系统架构图，就拿着 STRIDE 逐项过一遍，基本不会漏掉大头。
| 威胁类型 | 英文全称 | 核心含义 | 举个栗子 |
|---|---|---|---|
| S 欺骗 | Spoofing | 冒充他人身份 | 攻击者伪造 JWT Token 登录管理员账号 |
| T 篡改 | Tampering | 非法修改数据或代码 | 中间人篡改 HTTP 请求中的转账金额 |
| R 抵赖 | Repudiation | 否认做过某操作 | 用户声称“我没下过这个订单”，但系统无日志 |
| I 信息泄露 | Information Disclosure | 敏感数据被未授权访问 | API 返回了用户的手机号和身份证号 |
| D 拒绝服务 | Denial of Service | 系统资源被耗尽，无法服务 | 大量并发请求打爆登录接口 |
| E 权限提升 | Elevation of Privilege | 普通用户获得管理员权限 | 通过 SQL 注入拿到数据库 root 权限 |
我的小技巧： 每次做威胁建模时，在系统架构图上用不同颜色标注 STRIDE 对应的风险点。比如红色标“篡改”，蓝色标“信息泄露”。一眼就能看出哪里最危险。
3.2 威胁来源分析：谁在盯着你的系统？
威胁不是凭空冒出来的。你得搞清楚：谁有可能、为什么要攻击你？
我把威胁来源分成三类，你在项目中也可以这么分：
- 外部攻击者：脚本小子、黑产团伙、APT 组织。动机通常是钱、数据、或者单纯想炫技。
- 内部人员：离职员工、被收买的内鬼、甚至是不小心的运维。我遇到过最典型的案例——一个运维把数据库备份文件放在了公网可读的 S3 桶里，挂了三天才被发现。
- 第三方/供应链：你引用的开源库、云服务商、外包团队。还记得 Log4j 漏洞吗？那就是典型的供应链威胁。
避坑指南： 我曾经在一个项目中只分析了外部攻击者，忽略了内部威胁。结果上线后，一个测试账号因为权限过大，被内部员工用来查了全量用户数据。嗯，从那以后，我的威胁来源分析表里永远有“内部人员”这一行。
3.3 威胁库的使用：别自己从头造轮子
你想想看，安全行业发展了这么多年，常见的威胁早就被人总结成库了。直接用，别自己硬想。
我常用的威胁库有三个：
| 威胁库名称 | 维护方 | 特点 | 适用场景 |
|---|---|---|---|
| CAPEC | MITRE | 攻击模式分类，非常详细 | 做渗透测试、红蓝对抗时参考 |
| CWE | MITRE | 软件弱点枚举，偏代码层面 | 代码审计、安全设计评审 |
| OWASP Top 10 | OWASP | Web 应用最危险的 10 个漏洞 | Web 项目快速自查 |
怎么用？举个例子。你在做登录模块的威胁建模，发现可能存在“暴力破解”风险。这时候打开 CAPEC，搜索“brute force”，它会告诉你：
- 攻击原理是什么
- 攻击步骤有哪些
- 常见的缓解措施是什么
直接复制到你的威胁建模文档里，比自己瞎猜靠谱得多。
核心观点： 威胁建模不是让你凭空创造威胁，而是让你学会“检索”和“匹配”。威胁库就是你的字典。
3.4 知识体系总览：一张图看懂威胁建模
下面这张图，是我自己总结的威胁建模核心逻辑。你可以把它打印出来贴在工位上。
3.5 实战步骤：一次完整的威胁建模怎么做？
光说不练假把式。我给你一个可以直接用的四步法：
- 画图：画出系统架构图和数据流图。标出所有外部实体、进程、数据存储。
- 标边界：用虚线标出信任边界。边界两侧的交互，就是威胁的高发区。
- 套 STRIDE：对每个数据流，逐一问自己：这里能不能被欺骗？能不能被篡改？……
- 查库补全：打开 CAPEC 或 OWASP，搜索你怀疑的威胁类型，看看有没有遗漏。
我的习惯： 第四步我通常会花 15 分钟快速过一遍 OWASP Top 10，确保没有漏掉 Web 层面的常见威胁。虽然简单，但很有效。
3.6 避坑指南：新手最容易犯的三个错误
- 只关注技术威胁，忽略业务威胁：比如“用户批量查询他人订单”这种业务逻辑漏洞，STRIDE 里没有直接对应项，但危害极大。
- 威胁清单写得太抽象：不要写“存在信息泄露风险”，要写“用户手机号在 API 响应中明文返回”。越具体，后续缓解措施越好落地。
- 做完威胁建模就不管了：威胁是会变的。系统每次迭代，都应该重新过一遍威胁建模。我曾经见过一个项目，半年前的威胁建模文档还在用，结果新加的功能全是漏洞。
好了，这一章的内容就是这些。记住：威胁建模不是一次性的“作业”，而是贯穿整个开发生命周期的“习惯”。