4. STRIDE模型详解（下）：Repudiation、Information Disclosure、Denial of Service、Elevation of Privilege
好，咱们接着聊。上一节我们把Spoofing、Tampering这两个家伙给收拾了，今天继续攻克剩下的四个：抵赖、信息泄露、拒绝服务、权限提升。这几个在实际项目中，我遇到的坑可不少，咱们一个一个来拆解。
4.1 Repudiation（抵赖）—— 干了事不认账
什么叫抵赖？说白了就是用户或者系统做了某个操作，事后说“我没干过”。比如用户转账了，然后说“我的账号被盗了，这不是我操作的”。你怎么办？
核心问题：系统无法提供足够证据，证明某个行为确实是由特定主体执行的。
实战案例：我之前帮一家金融公司做威胁建模，他们的交易系统有个漏洞——日志只记录了“转账成功”，但没有记录是谁发起的、从哪个IP、用的什么设备。结果真出了事，用户投诉说没转过账，公司赔了钱还找不到证据。
抵赖威胁的典型场景：
- 用户否认提交过订单
- 管理员否认修改过配置
- 系统否认发送过通知
怎么防？我个人的习惯是三个字：不可否认性。具体做法：
- 数字签名：每个关键操作都加上签名，比如用私钥签名交易数据
- 审计日志：日志要包含时间戳、用户ID、操作内容、源IP、设备指纹
- 日志防篡改：日志本身也要签名，或者写入区块链、WORM存储
避坑指南：我曾经遇到一个项目，日志倒是记录了，但日志文件存在应用服务器上。黑客攻破服务器后，直接把日志删了。嗯，这等于白干。日志一定要集中存储，并且只允许追加，不允许删除。
4.2 Information Disclosure（信息泄露）—— 不该看的看到了
信息泄露，这个大家应该不陌生。说白了就是敏感数据被不该看到的人看到了。比如密码明文存储、API返回了用户手机号、日志里打印了信用卡号。
实战案例：我记得有一次帮一个电商平台做安全评估，他们的订单查询接口，只要传一个订单号就能返回所有信息，包括收货人姓名、电话、地址。你想想看，如果有人写个脚本遍历订单号，那用户隐私全没了。
| 泄露类型 | 常见场景 | 危害等级 |
|---|---|---|
| 敏感数据泄露 | 密码、身份证、银行卡号 | 高 |
| 技术细节泄露 | 数据库结构、API密钥、堆栈信息 | 中 |
| 元数据泄露 | 文件创建时间、作者信息 | 低 |
怎么防？我建议从这几个方面入手：
- 数据分类分级：先搞清楚哪些是敏感数据，比如PII（个人身份信息）、财务数据
- 加密：传输用TLS，存储用AES，密钥管理要规范
- 最小权限：API只返回必要字段，别一股脑全给出去
- 错误处理：别把堆栈信息直接抛给用户，统一返回“系统繁忙”
注意：日志里千万别打印敏感信息！我见过一个项目，开发为了方便调试，把用户密码直接打到了日志里，结果日志文件被运维人员下载了。这锅谁来背？
4.3 Denial of Service（拒绝服务）—— 让你用不了
拒绝服务，说白了就是让系统变慢或者直接挂掉，合法用户用不了。常见的比如DDoS攻击、慢速攻击、应用层攻击。
实战案例：我之前参与过一个在线教育平台的项目。上线第一天，服务器就挂了。为什么？因为登录接口没有做限流，攻击者用几千个IP同时发登录请求，数据库连接池直接被打满。嗯，这就是典型的应用层DoS。
常见的DoS攻击类型：
- 网络层：SYN Flood、UDP Flood
- 应用层：HTTP Flood、慢速攻击（Slowloris）
- 资源耗尽：数据库连接池、文件描述符、内存
怎么防？我个人的经验是分层防御：
- 网络层：用WAF、CDN、DDoS清洗服务
- 应用层：限流（令牌桶、漏桶算法）、验证码、IP黑名单
- 资源层：连接池设置上限、超时机制、熔断降级
代码示例：简单的限流逻辑（伪代码）
# 令牌桶限流
def rate_limit(user_id):
bucket = get_bucket(user_id)
if bucket.tokens > 0:
bucket.tokens -= 1
return True # 允许
else:
return False # 拒绝避坑指南：我曾经见过一个团队，限流只做了IP维度。结果攻击者用分布式代理，每个IP只发少量请求，绕过了限流。所以建议做多维度限流：IP + 用户ID + API路径 + 设备指纹。
4.4 Elevation of Privilege（权限提升）—— 小兵变将军
权限提升，说白了就是普通用户干了管理员才能干的事。比如普通用户通过修改URL参数，访问了管理后台；或者通过SQL注入，拿到了管理员权限。
实战案例：我记得有个社交平台，他们的权限校验只在前端做了。普通用户把浏览器里的角色从“user”改成“admin”，就能看到所有用户的私信。你想想看，这多可怕。
权限提升的两种类型：
| 类型 | 说明 | 例子 |
|---|---|---|
| 垂直提权 | 低权限用户获得高权限 | 普通用户变成管理员 |
| 水平提权 | 同权限用户访问他人数据 | 用户A看到用户B的订单 |
怎么防？我建议从这几个方面入手：
- 服务端校验：所有权限判断必须在后端做，前端只是展示
- 最小权限原则：每个用户只给完成工作所需的最小权限
- 权限矩阵：用表格明确每个角色能做什么、不能做什么
- 参数校验：用户ID、订单ID等参数，必须校验是否属于当前用户
注意：千万别相信前端传过来的角色信息！我见过一个项目，权限判断直接读前端cookie里的“role”字段。攻击者改一下cookie，直接变管理员。这种低级错误，真的会出大事。
4.5 四个威胁的对比总结
好了，四个威胁都讲完了。咱们来个小总结，方便你记忆：
| 威胁 | 核心问题 | 防御思路 |
|---|---|---|
| Repudiation | 干了事不认账 | 数字签名、审计日志、防篡改 |
| Information Disclosure | 不该看的看到了 | 加密、最小权限、错误处理 |
| Denial of Service | 让你用不了 | 限流、WAF、资源隔离 |
| Elevation of Privilege | 小兵变将军 | 服务端校验、权限矩阵 |
我个人习惯在做威胁建模时，把这四个威胁放在一起看。为什么呢？因为它们经常相互关联。比如信息泄露可能导致权限提升，权限提升后又可能引发抵赖。你想想看，是不是这个理？
好，这一节就到这里。下一节咱们开始讲STRIDE的实战应用，我会拿一个真实系统来完整走一遍威胁建模流程。到时候见！