1. 项目概述：从“知道名字”到“理解本质”
在网络安全领域，尤其是Web应用安全测试中，CSRF和SSRF是两个高频出现的漏洞类型。很多刚入门的朋友，包括我当年也一样，常常把它们搞混，或者只知其名，不知其所以然。今天，我就以一个过来人的身份，结合我这些年挖洞、审计、修复的经验，来给大家掰开揉碎了讲讲这两个漏洞。这不仅仅是一个简单的概念对比，更是一个从原理到实战，再到防御的完整闭环。我的目标是，你看完这篇东西，不仅能清晰地区分CSRF和SSRF，更能理解它们是如何被利用的，以及在实际渗透测试或代码审计中，你该如何去发现、验证和思考绕过方案。
简单来说，CSRF（跨站请求伪造）的核心是“借刀杀人”，利用的是用户在浏览器端的身份认证状态，欺骗用户的浏览器向一个他认证过的网站发送恶意请求。而SSRF（服务器端请求伪造）的核心是“挟天子以令诸侯”，攻击者诱使服务器应用向攻击者指定的内部或外部资源发起请求，从而探测或攻击内网服务。一个发生在客户端浏览器与服务器之间，另一个则发生在服务器与其它服务器（或内部服务）之间。理解这个根本区别，是后续一切学习的基础。
2. 核心漏洞原理深度拆解
2.1 CSRF：信任的滥用与身份劫持
CSRF攻击之所以能成立，建立在几个关键的前提之上，我习惯称之为“CSRF攻击三要素”：
- 用户已登录并保持会话：用户浏览器中存有目标站点（例如银行网站
bank.com）的有效Cookie或Session ID，代表其身份认证状态。 - 目标站点存在可预测的操作接口：比如修改邮箱的接口是
POST /change_email，转账接口是POST /transfer。这些接口没有对请求来源进行不可伪造的校验。 - 用户被诱骗访问恶意页面：攻击者构造一个包含恶意请求的页面（可能是一个论坛帖子、一封邮件里的链接、一个恶意网站），用户在其登录状态未过期时访问了该页面。
攻击流程可以这样形象化理解：你（用户）登录了银行网站（bank.com），然后没有关闭页面，又去逛了一个恶意论坛。论坛里一个看似普通的图片标签<img src="http://bank.com/transfer?to=attacker&amount=10000">，在你加载页面时，浏览器会自动向银行网站发起一个GET请求。因为你的浏览器里带着银行的登录Cookie，银行服务器看到这个请求，就会认为是你本人想转账，于是操作被执行。这就是最经典的GET型CSRF。
注意：现代应用更多使用POST请求执行重要操作，但CSRF攻击同样可以通过构造一个自动提交的隐藏表单（利用
<form>和<iframe>或JavaScript）来实现POST请求的伪造。关键在于，整个请求的发起完全由用户的浏览器在用户不知情的情况下完成。
核心原理：Web的会话管理机制（主要是Cookie）在默认情况下，浏览器会在向同源站点发起请求时自动携带。CSRF攻击正是滥用了这种“自动携带信任凭证”的机制。服务器无法区分一个带着正确Cookie的请求，到底是用户本人在页面上点击按钮发出的，还是从一个第三方恶意页面“飘”过来的。
2.2 SSRF：让服务器成为你的攻击跳板
SSRF的原理则完全不同，它的攻击面在于服务器本身的功能。很多Web应用提供了从服务器端发起网络请求的功能，例如：
- 网页内容抓取（如预览功能、RSS阅读器）。
- 文件导入（从指定URL导入数据）。
- 图片处理（从URL加载图片进行缩略或水印）。
- 内部系统接口调用（微服务架构中，服务A通过URL调用服务B）。
如果这些功能没有对用户传入的URL参数进行严格的过滤和限制，攻击者就可以操控服务器向任意地址发起请求。这带来了几个严重的威胁：
- 攻击内网服务：服务器通常位于内网，可以访问外部无法直接到达的内部系统（如数据库管理界面
172.16.0.10:8080、Redis服务127.0.0.1:6379）。通过SSRF，攻击者可以扫描内网资产，甚至直接攻击这些脆弱的内网服务。 - 本地文件读取：利用
file://协议，尝试读取服务器本地的敏感文件，如file:///etc/passwd。 - 端口扫描：通过判断请求的响应时间或错误信息，探测服务器内部或外部特定IP的端口开放情况。
- 绕过访问控制：如果服务器对某些IP有访问白名单，攻击者可以诱使服务器以自身（
127.0.0.1）的身份去访问这些受保护资源，实现绕过。
核心原理：SSRF的本质是“输入验证不严导致的功能滥用”。应用将用户可控的输入，未经充分校验就直接用作后端网络请求的目标地址，将内部或受信任的服务器资源暴露给了攻击者。
2.3 二者根本区别与联系
为了更直观，我把它们的核心差异总结成下表：
| 特性维度 | CSRF (跨站请求伪造) | SSRF (服务器端请求伪造) |
|---|---|---|
| 攻击发生点 | 客户端（用户浏览器） | 服务器端（应用服务器） |
| 利用条件 | 用户已登录目标站点，并保持会话 | 目标应用存在从服务器发起请求的功能，且参数可控 |
| 攻击目标 | 以用户权限执行特定操作（如改密、转账） | 探测或攻击内网服务/本地文件，或作为跳板 |
| 请求发起者 | 用户的浏览器 | 受害的Web应用服务器 |
| 依赖的信任关系 | 浏览器对Cookie的自动携带机制 | 服务器在内网或安全边界内的受信任地位 |
| 常见触发方式 | 诱使用户点击链接、访问恶意页面、加载图片 | 向存在漏洞的接口提交精心构造的URL参数 |
尽管两者都带有“请求伪造”，但方向截然相反。一个可以粗略地理解为“冒充用户”，另一个则是“驱使服务器”。在实际漏洞挖掘中，它们的发现方法和利用思路也完全不同。
3. 漏洞挖掘与利用实战指南
知道原理只是第一步，实战中如何找到并利用它们才是关键。下面我分享一些具体的思路和技巧。
3.1 CSRF漏洞的挖掘与利用
挖掘思路：
- 功能点枚举：重点关注所有具有状态改变功能的操作。例如：用户资料修改（邮箱、密码）、地址管理、资金操作（充值、转账）、内容发布/删除、权限设置等。
- 请求分析：使用Burp Suite等代理工具拦截这些操作的HTTP请求。观察关键点：
- 是否仅依赖Cookie/Session进行身份认证？请求头里除了Cookie，有没有其他随机Token？
- 参数是否可预测？比如，修改用户邮箱的请求，除了邮箱参数，是否需要一个固定的
userid参数？这个userid是否容易从其他页面获取？
- 验证是否存在防护：检查请求中是否存在以下常见的CSRF防护措施：
- CSRF Token：一个随机、不可预测的令牌，通常隐藏在表单的
<input type="hidden">字段中，或放在请求头（如X-CSRF-TOKEN）里。服务器会校验该令牌的有效性。 - 自定义请求头：例如，使用
X-Requested-With: XMLHttpRequest。但注意，这并非绝对安全，CORS配置不当可能被绕过。 - 校验Origin/Referer头：服务器检查HTTP请求头中的
Origin或Referer字段，判断请求是否来源于同源站点。
- CSRF Token：一个随机、不可预测的令牌，通常隐藏在表单的
利用POC构造：对于无防护或防护薄弱的点，可以快速构造概念验证（POC）页面。一个经典的POST型CSRF POC HTML如下：
<!DOCTYPE html> <html> <body> <!-- 利用用户当前对target.com的登录状态 --> <form id="csrfForm" action="http://vulnerable-target.com/api/change_email" method="POST"> <input type="hidden" name="email" value="attacker@evil.com" /> <!-- 可能还有其他必需的隐藏参数 --> </form> <script> // 页面加载后自动提交表单 document.getElementById('csrfForm').submit(); </script> </body> </html>你只需要诱使已登录目标网站的用户访问这个HTML页面，攻击就会自动触发。
实战心得：
- 不要忽视JSON格式的请求：现在很多API使用JSON body。CSRF攻击JSON接口相对困难，因为简单的
<form>无法直接提交JSON。但可以通过构造一个发送JSON的JavaScript脚本来实现，或者如果服务器端解析存在缺陷（如同时支持表单和JSON），仍有利用可能。 - 关注CORS配置：如果目标站点配置了宽松的CORS策略（如
Access-Control-Allow-Origin: *），结合自定义请求头，可能会给CSRF利用带来新的途径。 - 利用框架特性：一些老旧框架或特定配置下，CSRF Token可能存在于Cookie中且未与Session绑定，或者Token生成算法存在缺陷导致可预测，这些都可能导致防护被绕过。
3.2 SSRF漏洞的挖掘与利用
挖掘思路：
- 寻找“URL参数”：在渗透测试或代码审计时，密切关注所有接受URL或主机名作为输入的功能点。关键词包括：
url、link、path、file、feed、api、upload from URL、image fetch、proxy、webhook等。 - 参数注入测试：发现可疑参数后，尝试输入以下类型的Payload进行探测：
- 回显型SSRF：输入一个你能控制的公网服务器地址（如
http://your-burp-collaborator-domain），观察应用是否请求了该地址，并将响应内容（全部或部分）显示在页面上。这是最理想的情况。 - 盲SSRF：应用发起了请求，但响应不直接显示。你需要借助外部工具来检测请求是否发生，例如Burp Suite的Collaborator、DNSLog、HTTPLog等。提交类似
http://your-unique-id.dnslog.cn的地址，查看是否有DNS解析记录。
- 回显型SSRF：输入一个你能控制的公网服务器地址（如
- 协议探测：尝试使用不同协议来扩大攻击面：
file://：读取本地文件，file:///etc/passwd。dict://：探测端口和服务信息，dict://127.0.0.1:6379/info（可能泄露Redis信息）。gopher://：一个非常强大的协议，可以构造任意格式的TCP数据包，常用于攻击内网的Redis、Memcached、MySQL等服务。但很多现代网络库已不支持。http://127.0.0.1:8080/admin：探测本地管理界面。
利用链拓展：单纯的请求外部地址可能危害有限，真正的威力在于利用SSRF作为跳板，攻击内网脆弱服务。
- 内网资产探测：利用SSRF对常见内网IP段（如
192.168.0.0/16，172.16.0.0/12，10.0.0.0/8）和常见端口（80, 443, 8080, 22, 6379, 27017等）进行扫描。通过响应差异（状态码、响应时间、错误信息）来判断服务是否存在。 - 攻击特定服务：
- Redis未授权访问：如果发现内网开放6379端口，可尝试利用SSRF向Redis发送命令。例如，通过
dict协议或精心构造的HTTP请求（如果Redis存在HTTP漏洞）来写Webshell。 - 攻击FastJSON等反序列化漏洞：如果内网存在Java应用并使用特定组件，可构造恶意的JSON请求触发反序列化漏洞。
- 访问元数据服务：在云服务器环境中，可以尝试访问云厂商提供的实例元数据地址（如AWS的
http://169.254.169.254），获取Access Key等敏感信息。
- Redis未授权访问：如果发现内网开放6379端口，可尝试利用SSRF向Redis发送命令。例如，通过
实操心得：
- 绕过过滤技巧：开发人员可能会对输入进行简单的过滤，如黑名单包含
127.0.0.1、localhost。绕过方法包括：- IP地址变形：
127.0.0.1->2130706433（十进制）、0x7f000001（十六进制）、127.1、127.0.1。 - 域名重定向：使用短链接服务，或者自己控制一个域名，将其A记录指向
127.0.0.1。 - 利用URL解析差异：
http://foo@127.0.0.1、http://127.0.0.1:80@evil.com。不同URL解析库（如Java的URL类、HttpURLConnection， Python的urllib， PHP的cURL）对这类格式的解析可能存在差异，可能导致绕过。 - 利用非标准端口：
http://127.0.0.1:80可能被过滤，但http://127.0.0.1默认就是80端口。
- IP地址变形：
- 注意出网协议：服务器发起的请求可能受到操作系统或运行环境防火墙的限制，可能只允许HTTP/HTTPS出网。因此
gopher、dict等协议不一定可用，需要测试。
4. 靶场实战演练与技巧解析
理论结合实践才能融会贯通。DVWA（Damn Vulnerable Web Application）和PortSwigger的Web Security Academy都是极好的练习平台。这里我以DVWA的CSRF模块为例，分享一些通关思路。
4.1 DVWA CSRF（Low级别）
场景：一个简单的修改密码页面，请求为GET /vulnerabilities/csrf/?password_new=123&password_conf=123&Change=Change。攻击：由于是GET请求，且无任何Token防护，构造一个包含该URL的图片标签或链接即可。
<img src="http://靶场地址/vulnerabilities/csrf/?password_new=hacked&password_conf=hacked&Change=Change" />诱使已登录DVWA的用户访问此页面，其密码就会被修改。要点：理解GET请求的CSRF是最直接的形式。
4.2 DVWA CSRF（Medium级别）
场景：服务器端尝试检查HTTP_REFERER头，判断请求是否来自本站。绕过思路：
- Referer检查不严谨：代码可能只是检查
REFERER中是否包含主机名（如192.168.x.x）。我们可以将攻击页面放置在可控的子域名或路径下，使其REFERER包含目标主机名。例如，如果靶场地址是http://192.168.1.100/dvwa/，我们可以将攻击页面放在http://192.168.1.100/evil.html（假设web根目录可写），或者通过http://dvwa.attacker.com（如果域名解析可控）并确保REFERER检查逻辑有缺陷。 - 利用浏览器行为：某些浏览器在从HTTPS页面跳转到HTTP页面时，或用户手动在地址栏输入时，可能不发送
REFERER头。可以尝试诱导用户从这类场景触发请求。实操：通常，DVWA Medium级别的防护可以通过在攻击页面中使用<meta name="referrer" content="no-referrer">标签来移除Referer头，或者将攻击页面命名为index.html放在靶场IP的根目录下（如果允许）来绕过。关键在于理解服务器校验Referer的具体逻辑并寻找其缺陷。
4.3 DVWA CSRF（High级别）
场景：引入了Anti-CSRF Token。每次访问修改密码页面时，都会生成一个随机的Token，并作为隐藏字段包含在表单中。提交修改请求时，必须携带正确的Token。绕过思路：这需要更高级的技巧，通常依赖于应用的其他漏洞组合拳。
- XSS + CSRF：如果同站存在一个XSS漏洞，攻击者可以利用XSS来窃取当前页面的CSRF Token，然后用这个Token来构造一个合法的CSRF请求。这是最常见的组合利用方式。
- Token预测/泄露：如果Token生成算法不安全（如基于时间戳），或者Token通过其他途径泄露（如日志、错误信息、JSONP接口），则可能被预测或获取。实操：在纯粹的CSRF上下文下，High级别通常是无法直接绕过的。它旨在告诉我们，一个真正随机的、与用户会话绑定的Token是防御CSRF的有效手段。练习这个级别，更多的是理解“为什么Token是有效的”以及“在什么情况下Token防护会失效”。
重要提示：在真实环境进行任何安全测试前，必须获得明确的书面授权。未经授权的测试是违法行为。
5. 防御方案设计与最佳实践
理解了攻击，才能更好地防御。下面分别给出针对CSRF和SSRF的防御建议。
5.1 CSRF防御的“组合拳”
单一的防御措施可能存在被绕过的风险，建议采用多层次防御。
使用同步令牌（Synchronizer Token Pattern）：这是最主流、最有效的方案。
- 实现：服务器在用户会话中生成一个高强度随机数作为CSRF Token，同时将其输出到表单的隐藏字段或Meta标签中。当用户提交表单时，前端脚本（或框架自动）将此Token随请求一起提交（通常在表单字段或自定义头如
X-CSRF-TOKEN中）。服务器验证提交的Token是否与会话中存储的Token一致。 - 关键：Token必须不可预测、与用户会话绑定、一次性使用（或短生命周期）。对于重要的操作（如转账），即使使用Token，也应考虑要求二次验证（如密码、短信验证码）。
- 实现：服务器在用户会话中生成一个高强度随机数作为CSRF Token，同时将其输出到表单的隐藏字段或Meta标签中。当用户提交表单时，前端脚本（或框架自动）将此Token随请求一起提交（通常在表单字段或自定义头如
校验Origin/Referer头：作为辅助手段。
- Origin头：对于同源请求和跨域CORS请求，浏览器会发送
Origin头。服务器可以校验该头是否来自预期的源（域名、协议、端口）。它比Referer更可靠，因为浏览器在某些隐私模式下可能不发送Referer，但会发送Origin。 - Referer头：检查请求是否来自本站页面。但需注意，如果网站存在开放重定向漏洞，攻击者可能构造来自本站
Referer的恶意请求。且Referer可能被用户或浏览器策略屏蔽。 - 实践：优先使用
Origin头校验，并做好Referer缺失时的降级处理（如拒绝请求或要求更强验证）。
- Origin头：对于同源请求和跨域CORS请求，浏览器会发送
设置Cookie的SameSite属性：现代浏览器支持的特性。
SameSite=Strict：Cookie仅在同站请求（即当前页面URL与请求目标URL的eTLD+1相同）时发送。这能完全阻止第三方发起的CSRF，但可能影响用户体验（例如从邮件链接点回网站，登录状态会丢失）。SameSite=Lax（默认值）：在跨站请求中，仅对安全（HTTPS）的顶级导航（如点击链接）发送Cookie，而对子资源请求（如图片、脚本）和POST表单不发送。这是一个很好的平衡点，能防御大多数CSRF攻击。SameSite=None：Cookie在所有上下文中发送，但必须与Secure属性一起使用（即仅限HTTPS）。这是为了兼容某些跨站场景（如嵌入的支付iframe）。
实施用户交互验证：对于关键操作（资金、改密、删库），强制要求用户进行二次确认，如输入登录密码、短信验证码、使用U盾等。这虽然不是纯粹的CSRF防御，但能极大增加攻击门槛。
5.2 SSRF防御的“白名单与沙箱”
SSRF防御的核心思想是“限制与隔离”。
输入验证与白名单：这是最根本的防御。
- 非必要不提供此功能：首先评估从服务器发起外部请求的功能是否真的必要。
- 使用白名单：如果必须，应严格定义允许访问的域名或IP地址列表，并在服务器端进行校验。白名单比黑名单可靠得多。
- 解析与校验URL：使用权威的URL解析库获取
host，然后进行判断。避免使用正则表达式等容易出错的方法。同时，需要解析并阻止使用非HTTP/HTTPS的危险协议（如file://，gopher://，dict://），除非业务明确需要。
网络层隔离与限制：
- 最小权限原则：运行Web应用的服务器（或容器）应该配置严格的网络出口防火墙规则，只允许访问其业务必需的外部地址和端口。例如，禁止访问内网RFC 1918地址段（
10.0.0.0/8，172.16.0.0/12，192.168.0.0/16）和回环地址（127.0.0.0/8）。 - 使用跳板机或代理：如果应用需要访问大量外部资源，可以设置一个专用的、受严格控制的代理服务器或网络出口网关。所有外部请求都通过这个代理发出，并在代理层实施统一的安全策略（如URL过滤、速率限制、目标限制）。
- 最小权限原则：运行Web应用的服务器（或容器）应该配置严格的网络出口防火墙规则，只允许访问其业务必需的外部地址和端口。例如，禁止访问内网RFC 1918地址段（
应用层沙箱与重定向控制：
- 禁用URL重定向跟随：确保使用的HTTP客户端库（如Python的
requests， Java的HttpURLConnection）默认禁止或严格限制自动重定向。攻击者可能利用重定向，先指向一个合法的白名单地址，再重定向到恶意地址。 - 响应内容检查：不要将服务器获取到的远程内容直接返回给用户。应对内容类型、大小进行检查，对于图片等文件，可以下载到本地后，使用安全的图形处理库重新渲染输出，避免潜在的“图片马”或恶意内容。
- 禁用URL重定向跟随：确保使用的HTTP客户端库（如Python的
定期更新与安全配置：
- 及时更新依赖库：用于发起网络请求的库（如
libcurl）可能存在漏洞，导致过滤规则被绕过。保持更新。 - 安全配置云元数据服务：对于云服务器，确保实例元数据服务（如AWS IMDS）使用的是v2版本（需要Token），并限制其访问范围。
- 及时更新依赖库：用于发起网络请求的库（如
6. 进阶思考与联动攻击
在真实的攻防对抗中，漏洞很少孤立存在。CSRF和SSRF常常作为攻击链中的一环，与其他漏洞结合产生更大的破坏力。
- SSRF -> 内网漏洞利用：这是SSRF最经典的联动。通过SSRF探测到内网存在一个未授权的Redis，进而利用Redis写文件功能获取Webshell；或者探测到FastJSON、Shiro等组件的反序列化漏洞，直接获取服务器权限。
- XSS -> 窃取CSRF Token -> CSRF：如前所述，一个存储型XSS可以窃取页面中的CSRF Token，从而绕过Token防护，实施精准的CSRF攻击。
- SSRF -> 读取本地文件 -> 获取敏感信息：通过
file://协议读取服务器上的配置文件，可能获得数据库密码、加密密钥、其他服务的访问凭证等，为进一步渗透铺平道路。 - CSRF + 逻辑漏洞：例如，在一个购物网站，CSRF可以用于重复提交优惠券领取请求（如果逻辑上未做幂等性校验），或者利用竞争条件完成高并发攻击。
理解这些联动可能性，能帮助我们在渗透测试时拓宽思路，在防御时构建更深层次的纵深防御体系。例如，仅仅防御了SSRF可能还不够，还需要确保内网服务本身是加固的；防御了CSRF，也需要检查是否存在XSS漏洞可能绕过Token防护。
7. 工具与资源推荐
工欲善其事，必先利其器。以下是我在挖掘和测试这两类漏洞时常用的工具：
- Burp Suite Professional：渗透测试瑞士军刀。其Repeater、Intruder模块用于测试参数和模糊探测；Collaborator是检测盲SSRF的神器；CSRF PoC Generator可以一键生成CSRF攻击页面。
- OWASP ZAP：一款免费的、功能强大的安全测试工具，同样具备代理、扫描、主动/被动测试功能，对CSRF Token的识别和测试有不错支持。
- SSRFmap、Gopherus：专门用于SSRF漏洞利用的工具。SSRFmap可以自动化进行内网探测和特定服务的攻击；Gopherus可以帮助你生成攻击Redis、MySQL等服务的Gopher协议Payload。
- DNSLog平台：如
dnslog.cn，ceye.io， 用于检测无回显的SSRF、盲打XSS等漏洞。 - 靶场环境：
- DVWA、bWAPP：包含从低到高各种难度的CSRF、SSRF漏洞场景。
- PortSwigger Web Security Academy：免费、高质量的交互式Web安全学习平台，其SSRF和CSRF实验非常经典，且紧跟现实世界漏洞。
- SSRF Labs：专门针对SSRF漏洞的练习靶场。
最后，我想强调的是，安全是一个持续的过程。无论是作为开发者在编码时践行安全设计，还是作为安全人员在测试时保持好奇与严谨，对CSRF和SSRF这类“经典”漏洞的理解深度，直接体现了你对Web安全基础架构的掌握程度。多动手搭建靶场练习，多阅读优秀的漏洞分析报告，多思考“如果我来攻击/防御，我会怎么做”，你的能力自然会在实践中快速增长。在真实测试中，遇到任何可疑的点，不要轻易放过，大胆假设，小心求证，往往最严重的漏洞就藏在那些看似不起眼的参数和功能里。
