事件分析

这里收 Web 侧的代表性真实事件。

不讲漏洞机制。 机制在上一级的机制篇里已经讲完了，这边不重复——每篇开头链回对应的机制，然后直接进入另一条线：

一个有安全团队、有扫描器、有审计的组织，为什么还是被打穿了。

为什么值得单独一个目录

因为一起事件里真正的教训，往往和漏洞本身没什么关系。以 Equifax 为例：

机制层面   Struts 的表达式求值 —— 属于「表达式语言注入」那一篇，一次讲完，
          和 Log4Shell、Spring4Shell 放在一起讲才讲得清

事件层面   ⭐ 这些在机制篇里放不下，但它们才是这起事件的内容：
          · 补丁公告发出后，扫描器没覆盖到那台机器
          · 流量检测设备的证书过期了 19 个月，期间等于没有检测
          · 网络没有分段，一个 web shell 直通数据库
          · 从入侵到发现，隔了两个多月

把代码写对，一条都挡不住。 这就是这个目录的理由。

每篇的结构

一、这是哪条机制        一段话 + 链到机制篇，不展开
二、时间线              从补丁公告 / 首次入侵，到披露
三、为什么没被拦住      资产清单 · 补丁流程 · 网络分段 · 权限边界
四、为什么没被及时发现   检测覆盖 · 日志留存 · 告警疲劳
五、响应过程            披露时机、口径、以及事后被追责的点
六、可迁移的结论        换一个组织、换一个技术栈，哪几条仍然成立
七、证据与来源          ⚠️ 逐条标注等级，见下
   思考题

证据等级

Web 侧的入侵记录在别人的私有日志里，公开信息的可靠性差别很大，所以每一条结论后面标等级：

⚠️ C 级不单独成篇。 这条是硬的——否则这个目录会慢慢退化成新闻剪报。

同一起事件里，机制和链路的等级常常不同：Equifax 的 CVE-2017-5638 是 A 级（补丁和 PoC 全公开），而从 web shell 到 1.47 亿条记录的完整链路只有 B 级，来源是国会监督委员会报告而不是技术复盘。这种差别要在文里写明，不能混着讲。

有些事件的细节之所以异常清楚，是因为进了法律文书——Capital One 的 SSRF 链路来自起诉书。这属于偶然，不是常态。

编排：候选事件

按它揭示的组织问题分组，不是按漏洞类型（那是机制篇的事）。

资产清单与补丁流程
   Equifax 2017        补丁发布 → 没扫到那台机器
   Log4Shell 2021      不是一次入侵，是全行业「我到底用没用」的排查危机
   Apache 2021.10      CVE-2021-41773：修补路径穿越的补丁自己又踩了一次
                       —— 检查放在了解码之前

检测与可观测性
   Heartbleed 2014     无声泄露：不留痕迹，事后无法判断是否被利用
   Cloudbleed 2017     边缘串扰，且泄露内容被搜索引擎缓存了下来

云上的权限边界
   Capital One 2019    SSRF → 实例元数据 → 对象存储
   Snowflake 2024      客户侧未开 MFA + 历史失窃凭据

构建与供应链
   SolarWinds 2020     构建系统本身被改
   Codecov 2021        一个 bash 脚本 + CI 环境里的密钥
   event-stream 2018   维护者把仓库交给了热心人
   xz-utils 2024       长期社会工程，后门只出现在发布包里

框架默认值
   Rails/GitHub 2012   批量赋值：改默认值，而不是发一份最佳实践文档

人与流程
   Uber 2022           MFA 疲劳轰炸 + 脚本里的硬编码凭据
   Twitter 2020        内部管理面板，社工拿到的
   LastPass 2022       两阶段：开发机 → 云端备份
   Citrix Bleed 2023   会话令牌泄露，MFA 因此形同虚设

还没有文章，这一页是编排。 上面是候选清单，写之前每一起都要按等级重核一遍——清单里的年份和描述现在只是编排用的标签，不是已核实的结论。

所有事件均已公开、已修复。这里追的是组织与流程，不提供可直接使用的攻击载荷；相关的机制细节在机制篇里，也只写补丁已发布多年的漏洞。