第3章 STRIDE威胁模型：从理论到实战的六把刀
STRIDE威胁模型，微软在2000年左右提出，至今仍是威胁分析的基础工具。说实话，我最早接触它时觉得就是六个词，背下来就完事了。后来在真实项目中踩了坑，才明白这六把刀怎么用、什么时候该拔哪一把，比背定义重要得多。
STRIDE是六个英文首字母的缩写：Spoofing（欺骗）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（权限提升）。每把刀对应一类安全属性被破坏的场景。我们一个一个来看。
核心思路：STRIDE不是让你对每个组件都套一遍六个词，而是根据组件和数据流的特点，挑选最可能发生的威胁。
3.1 欺骗 (Spoofing) —— 你是谁？我凭什么信你？
欺骗，说白了就是伪身份。攻击者假装成合法用户、服务器或设备，绕过认证。我在项目中遇到过好几次：有个 IoT 平台，设备通过 MQTT 连接，证书是硬编码在固件里的。结果攻击者把证书提取出来，冒充任意设备发送指令。这就是典型的欺骗。
典型的欺骗攻击包括：
- IP/MAC地址伪造 —— 网络层的欺骗
- 重放攻击 —— 用合法凭据再次请求
- 中间人攻击 —— 拦截并替换通信双方身份
对抗欺骗的核心手段：强认证 + 非对称签名。你想想看，如果能证明私钥持有者，那伪造就很难了。
3.2 篡改 (Tampering) —— 数据在路上被改了
篡改攻击数据本身，或者传输中的报文。我印象最深的一次：一个金融接口，传输参数用的是明文JSON，中间人把转账金额偷偷改了。嗯，这就是没有完整性保护。
- 数据存储篡改 —— 数据库、文件被恶意修改
- 通信篡改 —— 报文在传输中被插入、删除、重排
- 代码篡改 —— 注入恶意代码或修改配置
防御方案：完整性校验（MAC、数字签名）+ 防篡改日志。我个人习惯对敏感数据同时做签名和时间戳，防止重放。
3.3 抵赖 (Repudiation) —— 干完不承认
抵赖就是用户或系统否认自己做过某个操作。这在合规场景里特别要命。比如用户说“我没转账”，而系统又拿不出证据。
我曾经给一个电商平台设计审计模块，用了强审计日志 + 非对称签名。每次关键操作，服务端签名一条日志，客户端也保留一条。这样双方都能举证。
防御要点：不可否认性 —— 数字签名 + 时间戳 + 安全的时间源（NTP）。不要相信客户端自己发的时间，服务器统一签发。
3.4 信息泄露 (Information Disclosure) —— 不该看的看到了
信息泄露通常是大家最担心的。数据被偷看、接口返回过多字段、日志里泄露密码……太多了。我检查过一个API，返回user对象里竟然把password_digest也一并返回了，前端根本不用的。
- 存储泄露 —— 数据库明文密码、密钥硬编码
- 通信泄露 —— 未加密的敏感传输
- 侧信道泄露 —— 响应时间、错误信息给出太多
防守原则：最小权限 + 数据分级 + 加密。对于日志，千万不要把密钥、密码、Session ID打进去，我在生产环境见过至少3次这种事故。
3.5 拒绝服务 (Denial of Service) —— 不让别人干活
拒绝服务不一定是像素级大流量攻击。资源耗尽、逻辑漏洞也可能导致服务不可用。比如一个递归查询接口，参数没有深度限制，攻击者用一条深度很高的JSON就能打崩CPU。
- 网络层DoS —— SYN Flood、UDP反射
- 应用层DoS —— 慢速攻击、递归炸弹
- 分布式反射 —— DDoS
对抗方法：限流 + 配额 + 请求验证 + 资源隔离。我建议在架构设计阶段就把“限流”当一等公民，而不是后期打补丁。
3.6 权限提升 (Elevation of Privilege) —— 越权搞事情
权限提升是STRIDE里最危险的，因为一旦突破，整个系统就沦陷了。分为水平越权（用户A看了用户B的数据）和垂直越权（普通用户执行管理员操作）。
我记得有个SaaS系统，用户ID是自增整数，修改URL里的id就能看到别人的订单。这种漏洞在渗透测试里非常常见。
防御：强制访问控制 + 服务端校验。前端校验只是用户体验，真正防越权必须在后端。我个人习惯在每一个数据查询里加上“AND user_id = ?”这种条件，避免遗漏。
3.7 一张图串起六把刀
下面是我个人画的一张STRIDE关系图。六个威胁不是孤立的，比如权限提升往往伴随信息泄露，拒绝服务可能掩盖其他攻击。我在项目中习惯用这张图做快速脑暴。
个人小技巧：做威胁脑暴时，在白板上画出这个六边形，每个角写一个威胁。然后拿着数据流图（DFD），问自己“这里数据经过这个组件，会不会被XXX？” 特别有效。
3.8 实战避坑点
我总结几个常见的误解：
- 每个组件套六个威胁 —— 这会导致文档又臭又长。建议根据组件作用选：比如认证模块重点关注Spofing/EoP；存储模块重点关注Tampering/Info Disclosure。
- 忽略“抵赖” —— 很多团队只做防篡改，不做不可否认。审计合规时被罚过才知道重要。
- 把DoS当外网防御 —— 内网DoS同样致命。比如一个服务对另一个服务的请求没有限流，一个突发就能打垮。
3.9 STRIDE与其它模型的关系
| 威胁模型 | STRIDE对应 | 适用场景 |
|---|---|---|
| PASTA | 偏流程风险，STRIDE做威胁分类 | 大型企业合规 |
| LINDDUN | 更细的隐私分类（不可链接性等） | 隐私影响分析 |
| 攻击树 | STRIDE给出威胁类型，攻击树细化攻击路径 | 红蓝对抗演练 |
注意： 不要为了用STRIDE而用。如果系统很简单（比如一个内部工具），可能只关注篡改和信息泄露就够了。灵活裁剪才是高手。
好了，这一章我们把STRIDE的六把刀拆了一遍。下次做威胁建模，试着直接在DFD上标注每个威胁的STRIDE类别，很快就能发现盲区。另外，我建议你拿一个自己的项目，跑一遍这六个威胁，看看你过去遗漏了哪些。