案例库 · 第三类：攻防技术场景
这一类练什么： 一个具体的攻击，到底是怎么打的、怎么一步步升级的。用「威胁建模」把攻击拆成链，看清楚”脆弱性在哪、威胁怎么走、影响多大”。
读法： 每个场景，先把自己当攻击者想一遍——“如果是我，我会怎么打？”
本类口诀： 漏洞的危害是”权限”和”链”决定的，不是”漏洞类型”决定的。
案例 11：SSRF 打云元数据（169.254.169.254）
问题： 为什么云安全圈一提到 169.254.169.254 这个 IP 就紧张？
案例： 在 AWS、阿里云等云平台上，每台云主机都能通过一个固定的链路本地地址（AWS 是 169.254.169.254）访问”元数据服务”，里面存着这台机器的实例信息、IAM 角色临时凭证。如果应用存在 SSRF 漏洞，攻击者就能让服务器替自己去请求这个地址，把凭证读出来——拿到凭证，就能以这台机器的身份访问云上的其他资源（如 S3/OSS 桶）。
一般人怎么想： “这不就是个内网地址吗？内网地址很安全啊，能有什么问题？”
咱们怎么想： 问题恰恰出在”内网=安全”这个老观念上。在云里，这个”内网地址”里住着”能开启一切的凭证”。 你的 SSRF，就是别人开这个保险箱的钥匙。
分析过程：
- 攻击链：SSRF → 请求
169.254.169.254/latest/meta-data/iam/security-credentials/...→ 拿到临时凭证 → 用凭证访问云资源。SSRF 从”打内网”升级成了”打云资产”。 - 脆弱性在哪：不只是 SSRF 这个代码漏洞，还有一层”信任边界错位”——应用以为自己请求的是”内网地址”很安全，但它没意识到，这个内网地址里住着”能开启一切的凭证”。
- 威胁怎么放大：一个 SSRF 本身可能只是”让服务器发个请求”，但一旦它摸到元数据服务，就拿到了这台机器在云上的全部身份。漏洞的价值，不在它自己，在它能摸到的东西。
- 三层防御：SSRF 修复（白名单校验目标地址、禁止访问链路本地地址段）+ IMDSv2（元数据服务强制加 token，给保险箱上锁）+ IAM 最小权限（就算凭证被偷，也偷不到太多）。
一句话启发： 云上有一个”藏在每台机器里的保险箱”（元数据服务）。你的 SSRF 漏洞，就是别人开这个保险箱的钥匙。别再用”内网=安全”的旧地图，去逛云时代的新战场。
案例 12：SQL 注入：从”读一行数据”到”拿下整台服务器”
问题： SQL 注入最多不就是”看到数据库里几行数据”吗？它怎么一步步变成”控制整台服务器”的？
案例： 假设一个登录接口把用户输入直接拼进 SQL：SELECT * FROM users WHERE name = '$input'。攻击者先注入 ' OR '1'='1 绕过登录；接着用 UNION SELECT 读出其他表的数据；然后用 INTO OUTFILE（MySQL）往网站目录写入一个 webshell 文件；最后用 xp_cmdshell（SQL Server）或 UDF 提权，执行系统命令，彻底拿下服务器。
一般人怎么想： “SQL 注入嘛，老掉牙了，最多就拖个库，看几行数据而已，能有多严重？”
咱们怎么想： 这就是”只看到第一层”。SQL 注入的危害是阶梯式的，你要看的是”它能爬到多高”——而”能爬多高”取决于数据库账号的权限。
分析过程：
- 阶梯式升格：
- 第一阶：读数据（
UNION拖库） - 第二阶：写文件（
INTO OUTFILE写 webshell） - 第三阶：执行命令（
xp_cmdshell/ UDF → RCE）
- 第一阶：读数据（
- 关键认知：评估 SQL 注入时，别只看”能不能读到表”，要看”数据库账号权限有多大、有没有写文件/执行命令的能力”。权限越大，注入的升格空间越大。
- 根治在”脆弱性”：参数化查询（预处理语句）是根治方案——它让 SQL 结构固定，用户输入只能是”数据”不能是”代码”。同时数据库账号最小权限（去掉写文件、执行命令权限）。
- WAF 的边界：WAF 能拦一部分，但能被绕过（编码、注释符、大小写变换）。根治靠代码，WAF 只是兜底。
一句话启发： 漏洞的危害是”权限”决定的，不是”漏洞类型”决定的。同样一个 SQL 注入，在最小权限下只是”看几行数据”，在高权限下就是”服务器沦陷”。看漏洞，要看它身后的”权限阶梯”。
案例 13：IDOR 越权：改一个参数，看到别人的订单
问题： 一个连”技术含量”都谈不上的漏洞，为什么是业务系统里最高发、最危险的一类？
案例： 某电商网站，用户查自己订单的接口是 GET /api/order?id=10086。后端只校验了”用户已登录”，没有校验”这个订单是不是这个用户的”。于是攻击者把 id 从 10086 改成 10087，就能看到别人的订单详情——姓名、地址、手机号、买了什么。这就是 IDOR（不安全的直接对象引用）/ 越权。
一般人怎么想： “这也叫漏洞？改个参数而已，一点技术含量都没有，真的有人会这么打吗？”
咱们怎么想： 正因为”没技术含量”，它才最高发、最危险——因为没有门槛，任何人都能打，而且直接拿真实用户数据。
分析过程：
- 脆弱性：水平越权（同级别用户之间互相访问）。攻击面是”对象 ID 直接暴露在参数里，且后端没做归属校验”。
- 为什么危险：① 没有技术门槛，脚本小子都能批量扫 ID 拖数据；② 直接拿真实用户数据（隐私、订单、手机号）；③ 工具很难发现——SAST/DAST 都不擅长测”业务归属逻辑”，这恰恰是”人工研判”的主场。
- 为什么工具难发现：因为”这个订单该不该归这个用户”是业务语义，不是代码里”有没有注入点”这种语法问题。机器读不懂”归属”，人才能。
- 防御：后端对每个对象访问做归属校验（这个 id 属于当前登录用户吗？），加统一权限框架、对象级访问控制。
一句话启发： 最值钱的数据，往往不是被 0day 偷走的，而是被”改个参数就看到了”。业务逻辑漏洞，是安全里最”笨”却最”要命”的一类——它没有技术门槛，所以它防不胜防。
案例 14：支付金额篡改（逻辑漏洞）
问题： 电商的”价格”是怎么被攻击者”改成 0.01 元”的？
案例： 某电商下单流程：用户选商品 → 前端把 amount=199.00 提交给后端 → 后端直接按这个 amount 调起支付。攻击者用浏览器抓包，把 amount 改成 0.01 再提交，后端没有重新从数据库核价，直接按 0.01 元创建了支付订单，成功”低价买走”高价商品。这就是典型的支付逻辑漏洞。
一般人怎么想： “安全不就是防注入、防 XSS 吗？那些我都做了啊，怎么还会出事？”
咱们怎么想： 安全不只是”防注入”，更要”防业务逻辑被人钻空子”。凡是”钱、权限、数量”这几个字出现的地方，都要问一句：这个值，服务端自己算了吗？
分析过程：
- 脆弱性：这不是注入、不是 XSS，是业务逻辑漏洞——后端”信任了前端传回的价格”。根因一句话：涉及钱、数量、权限的关键参数，绝不能由客户端决定。
- 为什么工具很难发现：SAST 扫不出”业务上该不该信前端”，DAST 也想不到”去改个金额试试”。它考验的是人”想”的能力：哪些参数是攻击者会去篡改的？
- 通用法则：看到”钱、权限、数量、身份”这几个字，脑子里自动弹一句——“这个值，服务端自己算过吗？”
- 防御：后端以数据库为准重新计价、服务端校验金额、关键操作加签名防篡改、金额用服务端会话保存。
一句话启发： 安全不只是”防注入”，更要”防业务逻辑被人钻空子”。凡是”钱、权限、数量”这几个字出现的地方，都要问一句：这个值，服务端自己算了吗？
案例 15：npm 供应链投毒（一个恶意依赖包）
问题： 你 npm install 一个包，怎么就把自己的服务器”装”给了攻击者？
案例： 攻击者发布一个名字很像常用包的恶意 npm 包（typosquatting，比如把 lodash 拼成 lodahs），或者抢注了某个冷门包名，在里面埋了后门——比如安装时执行脚本，把服务器的环境变量（含密钥）、.ssh 目录、npm token 上传到攻击者服务器。开发者一个疏忽敲错包名，或者一个被弃养的包被接管，公司就中招了。
一般人怎么想： “装个包而已，大家天天都在装，能出什么事？又不是我写的代码有问题。”
咱们怎么想： 现代开发是”站在一万个陌生人的代码上”。npm install 这个动作，等于”执行了别人写的、安装时能跑任意代码的脚本”。你以为你在装一个工具，其实你在执行一段陌生代码。
分析过程：
- 脆弱性在哪：攻击面是”开发者的依赖安装行为”。它钻的是”大家装包时不看内容”的惯性——这是流程上的脆弱性，不是代码里的。
- 威胁建模的关键一步：第三方依赖是典型的”信任边界外输入”。你要意识到：
npm install= 执行别人的安装脚本 = 给了对方”能在你机器上跑任意代码”的能力。 - 影响：安装脚本能偷走环境变量里的密钥、
.ssh私钥、npm token——这些是”能开启更多东西”的钥匙，偷走一个，后面连锁反应。 - 防御：锁死依赖版本、用私有源/代理审核、装包时加
--ignore-scripts、CI 里做依赖扫描、关键密钥不进环境变量。
一句话启发： 现代开发是”站在一万个陌生人的代码上”。“你依赖了谁”这件事本身，就是你的攻击面。 每次 install 前，都想想：我信任这段陌生代码了吗？
本类小结：五个场景，一条主线
这五个场景的共同主线，是**“漏洞的价值在链上，不在点上”**：
| 案例 | 点 → 链 | 关键升级 |
|---|---|---|
| SSRF 打云元数据 | SSRF → 凭证 → 云资产 | 内网地址里的保险箱 |
| SQL 注入 | 读数据 → 写文件 → 执行命令 | 权限决定升格高度 |
| IDOR | 改 id → 别人订单 | 没门槛，直接拿数据 |
| 支付篡改 | 改金额 → 低价成交 | 关键参数不能信前端 |
| npm 投毒 | install → 执行后门 | 依赖就是攻击面 |
看一个攻击，别只看”入口的那个漏洞”，要看”它接下来能连成什么链、摸到什么、升到多高”。 这才是”威胁建模”的意义——你越早看清链，越能在链条最便宜的地方把它剪断。