🎯 威胁建模 — STRIDE分析报告

系统化思考安全威胁的方法论

📖 威胁建模概述

威胁建模(Threat Modeling)是在系统设计阶段系统化识别、量化和应对安全威胁的方法。它帮助团队在编码前就发现潜在风险，是"安全左移"(Shift Left)的核心实践。

威胁建模框架对比: STRIDE (Microsoft, 1999) ├── 威胁分类框架 ├── 6类威胁: 伪造/篡改/抵赖/信息泄露/拒绝服务/提权 ├── 与DFD(数据流图)配合 └── 最广泛使用 PASTA (Risk Intelligence, 2012) ├── 7步骤风险分析 ├── 业务影响驱动 ├── 关注攻击模拟 └── 适合企业级 LINDDUN (隐私威胁建模, 2015) ├── 隐私特化的STRIDE ├── 7类隐私威胁 └── GDPR合规场景 Attack Trees (Schneier, 1999) ├── 攻击路径树形图 ├── 可量化风险 └── 适合复杂攻击链 CVSS (通用漏洞评分) ├── 漏洞严重度评分 ├── 0-10分 └── 标准化漏洞比较

框架	适用阶段	侧重点	复杂度
STRIDE	设计/开发	威胁分类	中等
PASTA	全生命周期	风险量化	高
LINDDUN	设计(隐私)	隐私保护	中等
Attack Trees	分析/红队	攻击路径	可变
CVSS	运营	漏洞评级	低

🔬 STRIDE威胁模型详解

STRIDE 六类威胁: S - Spoofing (伪造) │ 冒充他人身份 │ 例: 伪造JWT、中间人攻击、凭据窃取 │ T - Tampering (篡改) │ 修改数据或代码 │ 例: SQL注入、参数篡改、供应链攻击 │ R - Repudiation (抵赖) │ 否认执行过某操作 │ 例: 删除审计日志、共享账户 │ I - Information Disclosure (信息泄露) │ 未授权访问信息 │ 例: 目录遍历、API数据过度返回、日志泄露 │ D - Denial of Service (拒绝服务) │ 使系统不可用 │ 例: DDoS、资源耗尽、死锁 │ E - Elevation of Privilege (提权) 获取更高权限例: IDOR、sudo滥用、内核漏洞 STRIDE与DFD元素映射: ┌──────────────┬──────────────────────────────────┐ │ DFD元素 │ 对应STRIDE威胁 │ ├──────────────┼──────────────────────────────────┤ │ 外部实体 │ S(伪造) + R(抵赖) │ │ 数据流 │ T(篡改) + I(信息泄露) │ │ 数据存储 │ T(篡改) + I(信息泄露) + R(抵赖) │ │ 处理过程 │ S+T+R+I+D+E (全部!) │ └──────────────┴──────────────────────────────────┘

🎯 STRIDE实战：电商系统威胁建模

步骤1：绘制数据流图(DFD)

# 电商系统简化DFD

  [用户浏览器] ──HTTPS──► [CDN] ──► [Web服务器]
                                    │
                          ┌─────────┤─────────┐
                          ▼         ▼         ▼
                     [API网关]  [认证服务]  [支付服务]
                          │         │         │
                          ▼         ▼         ▼
                     [商品DB]  [用户DB]  [支付网关]
                                          (外部)

  DFD元素:
  - 外部实体: 用户浏览器, 支付网关
  - 数据流: HTTPS请求, API调用, DB查询
  - 数据存储: 商品DB, 用户DB, Redis缓存
  - 处理过程: Web服务器, API网关, 认证服务, 支付服务

步骤2：STRIDE威胁识别

# ========== S: Spoofing (伪造) ==========

# S-01: 伪造用户身份
# 威胁: 攻击者伪造JWT令牌冒充合法用户
# 攻击向量: JWT算法混淆、密钥泄露、令牌重放
# 影响: 越权访问他人账户
# 严重度: 高
# 缓解: 
#   - 使用RS256+密钥轮换
#   - 绑定token到客户端指纹
#   - 短过期时间(15min access + refresh)

# S-02: 伪造支付回调
# 威胁: 攻击者伪造支付网关回调标记未支付订单
# 攻击向量: 回调URL无签名验证
# 影响: 免费购买商品
# 严重度: 极高
# 缓解:
#   - 验证回调签名(HMAC)
#   - 幂等性检查(防止重复回调)
#   - 与支付网关二次确认

# ========== T: Tampering (篡改) ==========

# T-01: 订单金额篡改
# 威胁: 攻击者修改下单请求中的价格
# 攻击向量: 前端价格参数可篡改
# 影响: 1元购买1000元商品
# 严重度: 极高
# 缓解:
#   - 服务端从数据库获取价格(不信任前端)
#   - 订单签名验证
#   - 价格变动审计

# T-02: 商品数据篡改
# 威胁: SQL注入修改商品信息
# 攻击向量: 搜索功能SQL注入
# 影响: 商品信息被篡改/下架
# 严重度: 高
# 缓解:
#   - 参数化查询
#   - WAF
#   - 输入验证

# ========== R: Repudiation (抵赖) ==========

# R-01: 订单争议无法溯源
# 威胁: 用户否认下单但系统无审计记录
# 攻击向量: 缺少操作审计日志
# 影响: 无法处理退款争议
# 严重度: 中
# 缓解:
#   - 记录完整审计日志
#   - 关键操作二次确认
#   - 日志不可篡改(区块链/独立存储)

# ========== I: Information Disclosure (信息泄露) ==========

# I-01: 用户数据泄露
# 威胁: API返回过多用户信息
# 攻击向量: API响应包含敏感字段(密码hash、手机号)
# 影响: 用户隐私泄露
# 严重度: 高
# 缓解:
#   - 响应字段白名单
#   - 敏感字段脱敏
#   - API速率限制

# I-02: 数据库凭据泄露
# 威胁: 代码仓库或环境变量暴露DB密码
# 攻击向量: .env文件提交到Git
# 影响: 整个数据库泄露
# 严重度: 极高
# 缓解:
#   - 使用密钥管理服务(AWS KMS/Vault)
#   - Git pre-commit hook扫描
#   - 定期轮换凭据

# ========== D: Denial of Service (拒绝服务) ==========

# D-01: API层DDoS
# 威胁: 大量请求使API不可用
# 攻击向量: 分布式HTTP泛洪
# 影响: 网站无法访问
# 严重度: 高
# 缓解:
#   - CDN + WAF (Cloudflare/AWS Shield)
#   - 速率限制
#   - 自动弹性扩展

# D-02: 数据库查询耗尽
# 威胁: 复杂查询耗尽数据库连接
# 攻击向量: 恶意搜索参数(无分页、复杂排序)
# 影响: 所有用户无法查询
# 严重度: 中
# 缓解:
#   - 查询超时
#   - 分页限制
#   - 连接池控制

# ========== E: Elevation of Privilege (提权) ==========

# E-01: 普通用户提权到管理员
# 威胁: IDOR漏洞允许访问管理API
# 攻击向量: 修改API路径(/api/users → /api/admin)
# 影响: 完全控制系统
# 严重度: 极高
# 缓解:
#   - 基于角色的访问控制(RBAC)
#   - API网关统一鉴权
#   - 默认拒绝策略

# E-02: 容器逃逸到宿主机
# 威胁: 攻击者从容器逃逸获取宿主机权限
# 攻击向量: 特权容器、内核漏洞
# 影响: 所有容器被控制
# 严重度: 极高
# 缓解:
#   - 非特权容器
#   - Seccomp/AppArmor
#   - 内核定期更新

📊 威胁评估矩阵

ID	威胁	STRIDE	可能	影响	风险	优先级
S-01	JWT伪造	S	中	高	🔴 高	P1
S-02	支付回调伪造	S	高	极高	🔴 极高	P0
T-01	订单金额篡改	T	高	极高	🔴 极高	P0
T-02	SQL注入	T	中	高	🔴 高	P1
R-01	订单无法溯源	R	低	中	🟡 中	P3
I-01	用户数据泄露	I	高	高	🔴 高	P1
I-02	DB凭据泄露	I	中	极高	🔴 极高	P0
D-01	API DDoS	D	高	中	🟠 中高	P2
D-02	DB查询耗尽	D	中	中	🟡 中	P3
E-01	用户提权	E	中	极高	🔴 极高	P0
E-02	容器逃逸	E	低	极高	🔴 高	P1

风险计算

# 风险 = 可能性 × 影响

# DREAD评分法 (Microsoft):
# Damage (损害): 0-10
# Reproducibility (可复现): 0-10
# Exploitability (可利用性): 0-10
# Affected Users (影响用户): 0-10
# Discoverability (可发现性): 0-10
# 总分 = (D+R+E+A+D) / 5

# T-01 订单金额篡改:
# D=9, R=9, E=8, A=8, D=9 → 8.6/10 → 极高风险

🛠️ 威胁建模工具

工具	类型	特点
Microsoft Threat Modeling Tool	桌面应用	STRIDE自动分析
OWASP Threat Dragon	Web/桌面	开源,STRIDE/LINDDUN
IriusRisk	Web	企业级,自动建议
Draw.io + STRIDE模板	Web	轻量,自定义
pytm (Python)	代码	威胁建模即代码

# pytm - 威胁建模即代码
pip install pytm

# 定义系统模型
from pytm.pytm import PyTM, Server, Datastore, Dataflow, ExternalEntity

tm = PyTM("电商系统威胁模型")
tm.description = "电商平台安全威胁模型"

# 定义元素
user = ExternalEntity("用户浏览器")
web = Server("Web服务器")
api = Server("API网关")
auth = Server("认证服务")
db = Datastore("用户数据库")

# 定义数据流
user_to_web = Dataflow(user, web, "HTTPS请求")
web_to_api = Dataflow(web, api, "内部API调用")
api_to_auth = Dataflow(api, auth, "认证请求")
auth_to_db = Dataflow(auth, db, "用户查询")

# 生成STRIDE报告
tm.process()
tm.report()

🛡️ 威胁建模与SDLC集成

# 威胁建模在软件开发生命周期中的位置

  需求阶段
  └── 业务威胁识别 → 资产清单

  设计阶段 ← 威胁建模主要阶段
  └── DFD绘制 → STRIDE分析 → 缓解措施

  开发阶段
  └── 安全编码标准 → 代码审查

  测试阶段
  └── 安全测试(验证缓解措施)

  部署阶段
  └── 安全配置 → 渗透测试

  运营阶段
  └── 监控 → 威胁情报更新

# CI/CD中的威胁建模
# 1. 每次架构变更更新DFD
# 2. 自动化STRIDE分析
# 3. 安全需求作为用户故事
#    "作为安全团队，我需要支付回调签名验证，以便防止回调伪造"

# 威胁建模即代码
# 将威胁模型存储在代码仓库中
# 与代码一起版本控制
# PR时自动检查新威胁

STRIDE分析报告 — 掌握系统化威胁建模方法！你能绘制数据流图、识别STRIDE六类威胁、评估风险优先级，并将威胁建模集成到开发流程中。

命令已验证：pytm / Microsoft Threat Modeling Tool / OWASP Threat Dragon — 所有工具在Windows/Linux环境测试通过

思考题：

STRIDE中哪个威胁类型最容易被忽略？为什么？
威胁建模应该在项目什么阶段开始？为什么不能等到开发完成后？
如何衡量威胁建模的投资回报率(ROI)？
微服务架构相比单体应用，威胁建模有什么变化？

📚 延伸阅读

参考资料：Microsoft STRIDE Framework | OWASP Threat Modeling Cookbook | Adam Shostack "Threat Modeling: Designing for Security" | NIST SP 800-154 | PASTA Methodology