CSRF 与 SSRF 实战区分，附挖掘思路与防御方案-拓冰网站定制

CSRF 与 SSRF 实战区分，附挖掘思路与防御方案

前言

很多刚入行做 Web 渗透、漏洞挖掘的朋友，很容易把 CSRF 和 SSRF 搞混，两个名字都带 “请求伪造”，但攻击主体、攻击链路、危害场景完全不同。

CSRF（跨站请求伪造）是用户浏览器帮攻击者发起请求，利用用户已登录的身份；SSRF（服务端请求伪造）是目标服务器帮攻击者发起请求，利用服务器在内网中的网络位置。

在 SRC 漏洞挖掘、渗透测试过程中，经常会遇到这两类漏洞，但是测试方法、Payload、修复方案完全不一样。本文从原理、实战案例、快速区分技巧、挖掘思路、常见绕过，到生产环境防御方案一次性讲清楚，适合渗透测试、代码审计、安全开发学习。

免责声明：本文技术内容仅用于已获得书面授权的安全测试、网络安全学习。严禁在未授权业务系统上进行漏洞探测与攻击，未经授权的测试行为违反网络安全相关法律法规。

0x01 CSRF 跨站请求伪造原理

全称 Cross-Site Request Forgery，跨站请求伪造。
核心本质：利用浏览器自动携带 Cookie 的特性，诱导已登录用户，在不知情的情况下发起非预期请求。

攻击完整流程

用户登录目标网站 A，浏览器保存网站 A 的 Session Cookie；
用户没有关闭浏览器，访问攻击者搭建的恶意网站 B；
恶意页面中的图片、表单、JS 自动发起请求，访问网站 A 的接口；
浏览器自动带上网站 A 的 Cookie，网站 A 收到请求，认为是用户本人操作，执行请求。

关键点：攻击者拿不到用户 Cookie，只是利用浏览器自动携带 Cookie 的机制。

典型业务场景

修改个人邮箱、修改密码、绑定手机号；
提交表单、发布文章；
后台添加管理员、转账操作；
GET 型接口：shturl.cc/SUBOh0NK1EsQUtwrXiSxwRT95yh0vAjdbtOk1FBi，放在 img 标签中，用户访问页面自动触发。

简单恶意 POC 页面示例：

<img src="http://test.com/user/setemail?email=attacker@hack.com">

用户打开这个 HTML 页面，浏览器自动请求该地址，携带 Cookie，直接修改邮箱。

POST 型 CSRF 表单 POC：

<form action="http://test.com/user/changePwd" method="POST"> <input type="hidden" name="password" value="123456"> </form> <script>document.forms[0].submit()</script>

CSRF 利用前提（缺一不可）

用户已经登录目标站点，Cookie 有效；
接口仅依靠 Cookie 做身份认证，没有 CSRF Token、验证码、二次密码校验；
攻击者可以诱导用户访问恶意页面。

0x02 SSRF 服务端请求伪造原理

全称 Server-Side Request Forgery，服务端请求伪造。
核心本质：业务服务存在远程请求功能，用户可控 URL 传入后端，服务器主动去访问这个 URL。攻击者借服务器作为跳板，访问外网无法直达的内网资源。

攻击完整流程

业务接口接收用户传入的 URL 参数，服务端发起网络请求拉取内容（图片预览、网页摘要、webhook、图片代理）；
攻击者传入内网地址、本地回环地址、云元数据地址；
服务器在内网环境中访问目标地址，拿到内网服务数据；
服务器将返回内容回显给攻击者（有回显 SSRF），或者通过时间、状态判断内网端口存活（盲 SSRF）。

典型业务场景

网页预览、URL 截图、RSS 订阅；
Webhook 回调地址自定义；
图片远程抓取、头像远程下载；
PDF 生成，输入 URL 渲染页面。

Payload 示例：

# 访问本机后台管理面板 ?url=http://127.0.0.1:8080/admin # 读取本地文件 ?url=file:///etc/passwd # 云服务器元数据窃取（AWS） ?url=http://169.254.169.254/latest/meta-data/ # 内网端口扫描 ?url=http://192.168.1.100:3306

SSRF 利用前提

接口支持传入用户可控 URL；
后端使用 curl、file_get_contents 等函数发起请求；
没有对目标 IP、协议做严格过滤。

0x03 CSRF 和 SSRF 快速对比，实战区分

表格

对比项	CSRF 跨站请求伪造	SSRF 服务端请求伪造
请求是谁发起	受害者用户浏览器	目标业务服务器
信任对象	网站信任用户 Cookie	服务器信任外部传入的 URL
攻击目标	以用户身份执行业务操作（改密码、新增管理员）	内网主机、本地文件、云元数据、内网端口
是否需要用户登录	必须用户登录	不需要用户登录，只需要接口存在
攻击者能否直接访问目标	攻击者不能直接执行用户操作，需要欺骗用户访问页面	攻击者直接提交请求，不需要诱导其他人
危害	冒用用户身份执行业务操作，篡改账号数据	内网探测、读取本地文件、接管云服务器、内网服务攻击
核心检测点	请求是否携带随机 Token、Origin/Referer 校验	URL 参数是否可控，后端是否发起网络请求
防御重心	Token、SameSite Cookie、请求源校验	IP 黑名单 / 白名单、协议限制、DNS 重绑定防护

一句话区分记忆：

CSRF：骗人，浏览器代发包；SSRF：骗服务器，服务器代发包。

0x04 漏洞挖掘实战思路

4.1 CSRF 挖掘思路

重点寻找会修改业务状态的接口（增删改操作，查询类接口一般无危害）。

抓包，观察修改密码、修改邮箱、新增用户、表单提交这类接口；
检查请求参数中是否存在 CSRF Token：
- Token 固定不变、可预测 → 存在漏洞；
- 完全没有 Token 字段，仅依靠 Cookie 认证 → 大概率存在 CSRF；
检查请求源校验：是否校验 Referer、Origin 请求头；
构造 POC 页面，脱离目标站点，在本地打开页面，看操作是否成功执行；
优先级：管理员接口 > 普通用户账号修改接口。

CSRF 常见绕过场景

Referer 校验缺陷：仅判断 Referer 包含域名，没有完全匹配；
允许 Referer 为空，攻击者直接删除 Referer 头绕过；
Token 只在前端隐藏，后端不校验，只是前端展示。

注意：如果接口使用 Token 放在请求头（JWT、Authorization），且不是自动由浏览器 Cookie 携带，通常可以抵御 CSRF。

4.2 SSRF 挖掘思路

寻找业务中输入 URL，服务器去拉取资源的功能点。

寻找参数名：url、link、preview、webhook、imgurl、fetch；
基础测试：传入http://127.0.0.1，观察返回内容、响应时间、状态码变化；
协议测试：file://读取本地文件，gopher://、dict://拓展攻击；
IP 绕过测试：
- 域名 DNS 重绑定；
- IP 进制转换：127.0.0.1 转为十进制、八进制；
- 0.0.0.0、::1 等特殊回环地址；
区分有回显 SSRF、盲 SSRF：盲 SSRF 无返回内容，依靠请求延时判断端口是否开放；
云环境额外测试云元数据地址，是高危 SSRF 常见收益点。

SSRF 常见绕过场景

黑名单过滤127.0.0.1，但是不过滤域名解析到内网 IP（DNS 重绑定）；
只过滤 http 协议，没有禁用 file、gopher 协议；
只在前端做 URL 过滤，后端没有校验；
过滤localhost，但是没有过滤0.0.0.0、IP 简写。

0x05 实战中容易踩的误区

❌误区 1：名字都叫请求伪造，原理一样

完全不同。CSRF 攻击依赖受害者浏览器，必须社工诱导用户；SSRF 攻击者直接发包，不需要任何人参与。

❌误区 2：GET 请求才有 CSRF，POST 不存在

POST 表单同样存在 CSRF，只是构造 POC 稍微复杂，很多后台 POST 接口经常出现。

❌误区 3：SSRF 只能访问 http 协议

如果后端没有限制协议，file 读取本地文件，gopher 可以对内网 Redis、Mysql 发送指令，危害极大。

❌误区 4：SSRF 只需要过滤 127.0.0.1 就安全

黑名单不可靠，攻击者可以使用域名解析、IP 编码绕过，推荐白名单域名。

❌误区 5：加了 Cookie 就一定存在 CSRF

如果 Cookie 设置SameSite=Strict，或者接口使用自定义请求头 Token，CSRF 很难利用。

0x06 安全防御方案

CSRF 防御方案（开发落地）

CSRF Token（推荐首选）
用户会话生成随机唯一 Token，放入表单或者请求头，后端每次提交必须校验 Token 和会话绑定。
要点：每次会话刷新 Token，不能固定 Token。
Cookie SameSite 属性
设置 CookieSameSite=Strict或者 Lax，跨站场景浏览器不会自动携带 Cookie，现代浏览器原生防护 CSRF。
校验 Origin / Referer 请求头
校验请求来源域名，拒绝非可信域名的跨站请求。
注意：不能只做黑名单，同时兼容 Referer 为空的风险。
高危操作增加二次验证
修改密码、转账、新增管理员，增加短信验证码、旧密码二次确认。
高危操作禁止使用 GET 方法，GET 请求容易被图片、链接触发 CSRF。