1. 从题目说起：SSRF到底考什么CTF圈子里流传着一句话：“没有SSRF的Web题，就像没有鸡蛋的西红柿炒蛋。”话虽然有点夸张，但确实说明SSRF在Web方向里的地位——不说是必考吧，至少是高频考点。这段时间我一直在刷某CTF平台的SSRF专题，从最简单的file://协议读文件，到绕IP限制，再到最后用Gopher打内网服务，整个链路走下来，最大的感受是：SSRF考的不是某一个单一知识点，而是“服务端请求到底能被你控制到什么程度”的综合能力。很多新手看到“SSRF”三个字母就发怵，觉得这是渗透测试或者内网攻击才用的东西，离自己很远。其实没有想象的那么玄乎。SSRF的全称是Server-Side Request Forgery，服务端请求伪造。本质就一句话：服务端接收了用户输入的URL去请求资源，但程序没有严格校验这个URL是内网还是外网、是HTTP还是其他协议，于是攻击者就能借助服务端的“手”去访问本来不该让它访问的地方。CTF里考的就是你如何在各种限制条件下，把这个“手”伸得足够长。这期实战记录，我打算按照自己从基础到Gopher的完整做题路径来展开。含金量最高的不是某个payload本身，而是每走一步时脑子里应该有的判断逻辑：它为什么能绕、为什么不能绕、换了环境之后哪些结论要推翻重来。所以这篇文章不只是给刷题的朋友做参考，对搞开发、搞运维的朋友同样有启发——很多看似不起眼的“小问题”组合在一起，就是一条完整的攻击链。1.1 一道题引出的四个问题我通关的这个系列，起步题很简单，一个Web页面，里面有个输入框，输入URL点击提交，服务端会把请求结果返回给用户。这种题型即使没接触过CTF的人也能看懂：输入http://www.example.com，页面上就会展示该网页的部分内容，输入file:///etc/passwd，有可能就直接把本地文件内容读出来了。但真要拿高分，不是读个文件就完事，而是要面对下面这四道关卡式的问题：第一，服务端可能做了IP限制。你传一个内网IP过去，比如http://127.0.0.1，它能给你拦住，让你不得不去想各种绕过手段。第二，就算能访问内网IP，你还得确定内网里到底跑了什么服务。端口靠扫，协议靠猜，这一步本质上是在“带外探测”。第三，很多服务不是HTTP协议，普通URL请求根本打不过去，这时候就得换协议，最经典的就是Gopher。第四，就算用Gopher把请求写给内网服务了，怎么构造一个有效的请求，让对方把Flag吐出来，这又是另一个层次的问题。这四个问题刚好对应SSRF从入门到进阶的四个层次。我从第一题开始挨个踩，踩到最后才发现，这几个问题不是孤立的，而是在一道题里层层递进的。1.2 SSRF题目在CTF里的典型考法先给没怎么接触过CTF的朋友简单梳理一下SSRF的常见考法，心里有个框架之后再往下看具体的绕过技巧会轻松很多。我按难度排了个序，大致是这样：难度层级常见考点典型限制条件最终目标入门任意URL请求无限制或仅外网读本地文件、探测端口初级IP地址绕过禁止内网IP用十进制/十六进制/短域名绕过中级URL解析差异过滤关键字利用协议解析差异绕过进阶重定向与协议切换限定HTTP协议利用302跳转访问内网高难Gopher协议仅允许特定协议攻击内网Redis/MySQL等非HTTP服务这个顺序基本就是我刷题的顺序。每上一个台阶，限制条件就多一层，思考方式也要跟着换。最忌讳的就是背了一堆payload以后死板套用，因为不同平台、不同语言写的后端，对URL的解析方式完全不一样，同一条绕过技巧在这一题里能用，换一道题可能就失效。所以下面我会把每种手法背后的原理讲清楚，而不是只给结论。2. 基础绕过手法的原理与实操2.1 IP与域名的那些绕法先说最常见的坑：后端直接判断你传入的URL里有没有内网IP的特征。比如你输入http://127.0.0.1:8080/flag，代码一看解析出来的host是127.0.0.1，直接拒绝。这时候最常见的思路就是换一种形式表示同一个IP。不要小看IP地址的写法，一个127.0.0.1可以被写成好几种完全不同的形式。最容易理解的是整数形式：把IPv4地址转换成一个32位整数，比如127.0.0.1对应的整数是2130706433。不少后端校验的时候只会匹配字符串特征，比如127.0.0.1、10.、192.168.这些开头，它不认识2130706433，于是请求就直接放过去了。再进阶一点可以用十六进制：0x7f000001也等价于127.0.0.1。还有八进制写法、混合写法，甚至可以用127.1这种省略形式，操作系统在某些场景下也能正确解析。这一套组合拳打下来，凡是只做字符串匹配的弱校验基本都能绕过。但这里的“绕过”是有前提的，前提是后端的HTTP库在做DNS解析和连接的时候，本身认得这些特殊格式。我实测下来，不同的语言、不同的HTTP客户端表现差异很大，有的能解析2130706433，有的不能，所以做题的时候不能想当然，一定要在靶场上多试几种写法。各种IP变体的测试优先级，我一般这么排：十六进制形式：0x7f000001整数形式：2130706433混合八进制：0177.0.0.1省略写法：127.1IPv6映射地址：[::1]、[::ffff:127.0.0.1]这里有个关键点：最终能用的形式，不完全取决于校验代码，更取决于服务端实际使用的网络库。所以遇到某个形式失败，不要急着否定它，先确认网络库的类型再说。2.2 URL解析差异与协议混用第二道关卡里，我碰到的是关键字过滤。后端检测URL里有没有127.0.0.1、localhost、file、gopher这些关键词，有就直接拦。第一种思路当然是大小写绕过，因为有些语言在做字符串过滤时是大小写敏感的，但对URL解析和DNS解析本身是大小写不敏感的。于是FILE:///etc/passwd就能绕过对file的过滤。如果大小写不好使，就该往“解析差异”方向想了。后端拿到用户输入的URL后，往往会先做一层校验，再把同一个URL交给请求库去请求。问题就出在“校验”和“请求”这两步走的不是同一套解析逻辑：校验方可能用的是一种简单的字符串匹配或正则。请求方可能是Python的requests、PHP的curl、Node的axios，各不相同。这两者之间只要有任何一个细节不一致，就能构造出“校验时不匹配、请求时匹配”的URL。比如http://127.0.0.1@evil.com这种形式，依赖某些库在解析时会取@之后的部分作为真实地址，从而把请求发往127.0.0.1。而校验方如果只是看域名部分是不是白名单，可能看到evil.com就放行了。还有更刁钻的，URL里加额外路径、分号、反斜杠、重复斜杠等，都能干扰解析。我印象最深的是反斜杠绕过：部分HTTP库在解析URL时会把\当作/处理，但一些过滤正则里写的却是标准的/。于是把http://127.0.0.1\evil.com传给服务器，它能正常请求127.0.0.1，过滤正则却以为你在访问evil.com。需要提醒的是，这种利用解析差异的绕过方式非常依赖后端环境。同一个payload在一个靶场里通了，换个平台可能全挂。原因很简单：不同语言及其HTTP库对URL标准的实现程度不一样，处理@、\、多余的/等字符的行为也不一样。所以我强烈建议，每个绕过payload在碰到实际环境时，都要先小流量验证一下，别直接上大招。2.3 302跳转与重定向跟踪绕过IP限制的另一个经典思路是“借壳上市”：找一个合法的外网域名，让它返回一个302重定向到内网地址。后端如果只校验初始URL的域名而没禁用重定向，请求就会在后面跳转时直接打向内网。这个思路为什么好用？因为很多过滤方案只盯着用户最初的输入。你输入http://example.com/redirect?target=http://127.0.0.1，后端一看example.com是白名单域名，放行；example.com返回302，Location指向http://127.0.0.1；如果请求库默认跟随重定向，那么后面这次请求就直接打到内网了。做CTF最爽的地方在于，这个“壳”不一定要找真实外网域名，你可以自己搭一个简单的服务，或者直接在靶场环境里起一个本地服务作为跳板。这里有一个小坑：如果后端请求库在跟随重定向时会带上初始请求的部分头部，可能导致请求失败；另外如果重定向目标也被同样校验了，那就此路不通。所以第一件事是先摸清后端到底跟不跟重定向，这个可以用一个可控的外部地址来看日志，看有没有收到第二次请求来确定。一个已经有很多人踩过、但我还是要再强调的细节：302跳转只能解决“IP被拦”的问题，不能解决“协议被限制”的问题。如果后端明确禁用了Gopher协议，你跳转到gopher://也照样被拦。所以做题之前先理清楚限制条件到底卡在哪一层，别把两个问题混为一谈。3. 内网探测：拿到第一手情报3.1 用请求时间盲探端口绕过限制只是第一步，真正麻烦的开始是“进去之后不知道干什么”。服务端目前能替你发起请求，但你不清楚目标内网的拓扑结构，也不知道有哪些服务开着。这时候就需要借助SSRF做内网探测了。最简单的探测方式之一是用响应时间来判断端口是否开放。原理不复杂：目标端口开放时，服务端发起TCP连接会成功，体现在响应时间上会比较快；目标端口关闭时，连接会被拒绝，或者要等超时才能返回。我们只需要构造不同的URL，让后端去请求http://127.0.0.1:{port}/，然后观察每个请求的耗时差异。在靶场环境里，我通常会扫描一批常见端口，比如3306（MySQL）、6379（Redis）、8080（常见Web服务）、9200（Elasticsearch）等。每个端口发三次请求取平均值，把耗时明显不同的端口标出来，再去逐一验证。这种盲探方式有个可能让人抓狂的点：很多靶场把“请求结果”直接渲染在了页面上，端口不通和端口开放时返回的页面内容可能都是空白，只有看响应耗时才有区分度。所以我习惯用工具辅助，手动一个个输入URL太慢了，而且人眼看着实难分辨几百毫秒的差别。用脚本边请求边记录时间是效率最高的做法。千万要注意，探测过程应当控制频率，做好延时，避免对目标服务造成压力。CTF场景内往往没问题，但如果将来你在授权测试环境里，这种操作同样要谨慎，暴力扫描很容易触发告警甚至影响业务。3.2 协议探针构造思路端口探测只能告诉你“这有个端口开着”，但开着的到底是什么服务，还得继续猜。一个可靠的思路是利用“不同服务对不同协议请求的响应特征不同”来做判断。还是拿端口6379举例。如果你让后端发起一个HTTP请求http://127.0.0.1:6379/，Redis不会返回正常的HTTP响应，它会返回一些以-ERR开头的错误信息，或者直接把连接关闭。但这个“错误信息”本身就暴露了服务类型。类似的，如果目标是MySQL的3306端口，发一个HTTP请求过去，响应会是很乱的非文本字节，这时候你在响应内容里看到协议版本号等特征，也能确认这是MySQL。更深一层，有些后端允许我们指定协议前缀，比如直接请求gopher://127.0.0.1:6379/_，那服务端就会真的发一段Gopher协议格式的数据过去。如果Redis没有设置密码，这几乎等于把钥匙递到你手里了。这里面的核心原则是：把服务端当作一个“通用协议代理”，利用它返回的响应内容来判断目标服务的类型和版本。不需要一步到位，先把范围缩到最小，再逐个击破。3.3 探测结果的分析方法我自己在刷这一系列题目时总结了一套分析方法，分三步走：第一步，先列一个“可能存在的内网服务清单”。这个清单不用太复杂，一般就是Web服务、数据库、缓存、消息队列这些常见项。像Redis、MySQL这类服务经常在CTF中被作为最终攻击目标，是因为它们本身支持文本协议，便于通过Gopher构造请求。第二步，针对每个开放端口，用不同协议去探测，并记录响应差异。比如对同一个端口分别发送HTTP、Gopher甚至Dict协议的数据，看哪个返回的内容更能揭示服务类型。有时一次探测不干净，得多试几次。第三步，把探测得到的信息与题面结合起来。CTF里的SSRF题目一般都有一个很明确的“最终目标”，比如读取某个Flag文件、写入Webshell、或者篡改某个服务配置。把内网服务摸清楚之后，攻击路径往往就浮出水面了。我踩过的一个坑是过度扫描。在一道题里，我花了大量时间把所有端口都摸了一遍，结果发现真正需要的服务就是题面里提示的那个端口。CTF讲究的是时间和拿到Flag的效率，而不是面面俱到。先把题面里的暗示读明白，再去做定点探测，而不是无头苍蝇一样漫无目的地扫。4. Gopher协议：最犀利的武器4.1 Gopher协议到底是个啥Gopher协议出现得比HTTP还早，是一种互联网早期用于信息检索的协议。放到今天，它最大的价值在于“能让服务端主动向任意TCP服务发送任意格式的数据”。这一点对于SSRF利用来说太关键了：你别管它是什么服务，只要对方是监听在TCP端口上的，你就能用Gopher把构造好的原始数据包发过去。你需要理解的一个核心概念是：Gopher协议的数据格式非常灵活，它不限定“内容必须是HTTP格式”。我们可以用Gopher去往Redis发一条SET命令，也可以往MySQL发一段认证握手包。只要目标服务能解析TCP流并做出反应，理论上都可以尝试用Gopher去打。打个比方，HTTP请求像是一个“只会说一种语言的翻译”，碰到不懂HTTP的服务就抓瞎。而Gopher像是一个“原始字节传送带”，它不在乎谁在说话，只管把货送到。因为这一特性，Gopher成为SSRF攻击链路上从“能访问”到“能利用”之间最重要的一座桥。不过，使用Gopher也有一个前提：服务端发起请求的代码必须允许使用这个协议。很多后端库默认只允许HTTP/HTTPS，不让用gopher://这种前缀。所以当你发现URL里可以指定协议但被过滤掉gopher关键词时，第一反应应该是做编码绕过、参数污染，而不是直接认为“这题考的不是Gopher”。4.2 构造Gopher请求的注意事项构造Gopher请求时，第一件要做的事是URL编码。因为Gopher数据从格式上会被拼接到URL的路径部分，里面一旦出现?、&、%、空格、换行等特殊字符，就会干扰URL的解析，所以必须把整个数据块做一次URL编码。一个经典的格式是：gopher://127.0.0.1:6379/_数据内容_之后的部分就是你要发送的原始数据。如果是Redis命令，通常是一行一条命令，命令之间用\r\n分隔，多行之间也用\r\n分隔。然后把这整段内容做一次URL编码，再拼接到gopher://后面。我踩过的坑主要在两个地方。一个是换行符的处理。构造Redis命令时，很多人会直接用\n，结果命令在服务端解析时出错，因为Redis协议要求的是\r\n，两个字符缺一不可。另一个是重复编码。直接把已经编码过一次的数据再编码一次，会导致协议原文被破坏，服务端收到的不是你想发的命令。为了不在这类细节上反复折腾，我的经验是：先写一个最小的Python脚本，把要发送的协议数据打印出来看一眼，确认编码前与编码后的差异，再决定提交什么内容。肉眼确认一遍往往比URL编码器自动生成的结果更靠谱。4.3 拿Redis开刀的完整链路在CTF题目里，Redis几乎是Gopher攻击最经典的目标。原因有三点：默认监听在6379端口；经常以无认证方式运行；支持的命令集足够简单，一条SET、一条CONFIG SET就能做很多事。在一次靶场练习中，我的思路先是确定6379端口开放，然后用Gopher协议发了一条INFO命令，成功收到Redis的版本信息。确认无认证后，我尝试写入一个WebShell或者改写配置。构造Redis命令时，最需要注意的是批量协议格式。比如SET命令：*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n这里*3表示后面有三个参数，$3表示接下来的参数长度是3，依次类推。很多新手开始接触时会觉得这种格式“太绕了”，实际上这是Redis客户端与服务端通信的标准协议，抓包看一眼就明白了。用Gopher去打Redis，本质上就是替你手工把这个协议包拼出来。最后一步是把命令编码后作为Gopher请求体发送。如果成功，Redis里就会多出一条数据，接下来就根据题目要求去做对应操作。这里必须强调一点：以上所有操作都只适用于CTF靶场和授权测试环境，不能拿到真实生产环境里搞破坏。真实环境中的Redis如果暴露在外网，本身就是高危配置，务必做好访问控制、认证和网络隔离，而不是等别人来“教学”。5. 实战题目拆解：从过关到漏洞利用5.1 题目环境与信息收集我拿一道比较综合的题目来复盘整体思路。这道题给了一个提交URL的输入接口，提示业务方需要“获取网页快照”。它的限制条件是：请求必须从服务器发出，且只允许访问HTTP和HTTPS协议，IP地址不能是内网IP。看起来条件挺多，但实际上整个攻击链是这样的：第一步，提交一个外网正常的URL，比如某个我控制的服务地址，确认服务端能够发请求并把响应返回。第二步，尝试提交file:///etc/passwd，看协议是否被限制。如果被限制，就要考虑用302跳转或URL解析差异绕过，因为HTTP请求库通常不允许file协议。第三步，观察后端是否跟随重定向。用一个可控的外部服务器返回302跳转到http://127.0.0.1:80/，如果页面返回了本地Web服务的内容，说明重定向这条路线通了。第四步，用302跳转结合Gopher去访问内网的服务，做端口探测与服务识别。这个过程的每一步都可以在题面上找到“为什么这样设计”的线索。比如如果题目明明限制了协议却仍开放了重定向能力，那几乎就是明示你可以用跳板绕过协议限制。5.2 绕过过程的重点记录我在做这一题时的真实顺序是，先试了试http://127.0.0.1:8080/flag，直接提示“内网地址禁止访问”。然后我把IP改成整数形式http://2130706433:8080/flag，结果还是提示禁止。这说明校验不是简单字符串匹配，可能是解析后的IP也在黑名单里。于是我转向302跳转方案。自己在本地搭了一个简单的跳板服务，返回一个302响应，Location是http://127.0.0.1:80/。提交给靶场后，页面上出现了本地Web服务的默认页面。这个结果证明两件事：第一，后端跟随了重定向；第二，重定向目标不再被二次校验。有了这两条信息，后面再拿Gopher去打其他端口，就只是工程量的问题了。有个印象很深的细节：第一次构造302跳板时，我在Location里写的是http://localhost:80/，结果请求失败了，换成http://127.0.0.1:80/才成功。推测是后端对localhost做了额外的域名过滤。这种小坑看起来不起眼，实际排查起来很浪费时间，所以Debug时建议同一类型的域名、IP变体都试一轮，不要把宝押在一个写法上。5.3 最终利用与Flag获取探测内网服务时，我扫到6379端口开放。回到题面，它提到业务方“会缓存访问的结果”，这几乎就是在暗示存在Redis。于是构造Gopher请求，发送Redis命令，成功写入数据后，再回到首页读取，最终拿到Flag。整个过程真正困难的不是“最后一步的payload”，而是前面对各种限制条件的一次次试探。我甚至觉得SSRF题目做题到最后，拼的是“耐心”和“系统性”。一个请求失败了，到底是校验拦截，还是网络不通，还是协议不支持，要能很快判断出来；判断不出来，就用替代方案交叉验证。像我这次遇到的302跳板，如果本地测试时没有先在外网可控地址上确认返回码，后面整个链条都走不下去。这类题还有一个特别突出的人为因素：题目环境往往会预留大量的“线索注释”，包括代码片段、提示信息等。做题前先把所有线索读清楚，往往能少走一半弯路。比如题面里写了一句“业务方希望给每个网页生成快照”，这意味着什么？意味着后端一定有一个“根据URL发起请求并保存内容”的过程，这本身就是SSRF的典型成因。6. 高频踩坑点与排查思路6.1 请求总是失败？先查这三个我做SSRF系列踩过的坑不少，总结下来最常出问题的三个点，分别是URL编码、协议白名单、重定向策略。很多请求失败并不是因为思路不对，而是因为在这些基础细节上翻车了。先说URL编码。Gopher请求中只要包含?、&、%、空格、#等字符，就必须编码，否则URL解析时会被切分。新手最容易出错的地方是忘记对?编码，导致Gopher数据里的参数被当成URL的query string。我的建议是，构造完请求后先用工具解码一遍，确认最终发送的字节和预期一致。这比直接在页面上硬试高效得多。再说协议白名单。很多后端允许http与https，但对gopher、dict、file有限制。遇到这种情况，不能直接断言“这题打不了”，而是先看白名单是怎么实现的。如果只做了字符串前缀匹配，里可能藏有大小写、双重编码、换行绕过等空间。如果白名单真的锁得很死，还可以考虑302跳转带出来，因为重定向目标有时候不会再做一次协议校验。最后是重定向策略。有些请求库默认不跟随重定向，有些默认跟随，还有一些需要额外的参数才能支持。这一点直接决定302路线是否可用。一个实用的排查办法是：自己控制一个外部服务，让它返回302，然后在服务端日志里看有没有第二次请求过来。有，说明跟；没有，说明这条路被切断了。6.2 编码与协议细节的常见误区还有一个容易让人困惑的问题是“双重编码”。很多人会在构造Gopher payload时，先手动把数据做了一遍URL编码，再交给框架做一次自动编码，结果发出去的数据完全变形。拿Redis命令举例，一条SET mykey myvalue，编码前的原始字节是SET mykey myvalue\r\n，编码后变成SET%20mykey%20myvalue%0d%0a，再次编码就不是同一个东西了。在实战中，我最推荐的流程是：先用Python或在线工具把原始数据转换成URL编码形式，然后在提交时检查浏览器网络请求里的最终URL。如果发现URL里的%符号又被编码成了%25，那说明框架自动编码了一次，需要调整策略。另外，Redis协议的裸CRLF也是一大坑。有些编辑器或者手写脚本时，\r\n会被悄悄替换成\n，直接把协议包弄坏。用字节序列打印工具确认一下，能把这类问题扼杀在摇篮里。协议细节虽小，一旦出错，往往表现为“请求发出去了但服务端没有任何反应”，排查起来十分吃力。所以我的习惯是，每构造一个新的payload，最先做的不是提交到靶场，而是本地起一个简单的TCP监听服务，把Gopher协议实际发送的字节原样收下来看一眼。确认字节对了再上靶场，成功率会高出一大截。7. 从攻击视角回到防御视角聊了这么多攻击和利用技巧，最后想花点篇幅讲述防御端的思考。因为只懂进攻不懂防御，很容易让人觉得CTF打得好但在真实业务里使不上劲。反过来，理解了攻击者的思路，才能真正理解为什么SSRF这么危险，以及防御时要关注哪些点。SSRF的根因是“服务端发起了用户可控的请求”。所以最简单有效的防御是尽量不让用户直接控制目标URL。如果业务确实需要接受URL，那就必须做白名单校验：协议只能允许HTTP/HTTPS，IP解析结果必须经过二次确认，域名解析后如果是内网地址就直接拒绝。第二个关键点是重定向。很多防御方案只校验第一跳，结果攻击者用一个外网302就打进去了。因此更完善的方案是，在跟随重定向的每一跳上都执行同样的校验逻辑，而不是只校验初始URL。同时推荐默认关闭自动跟随重定向的选项，定点打开才更安全。第三个点是协议层控制。如果后端通过类似Requests这样的库发起请求，务必确认库支持的协议范围。很多后端代码里直接写死urlopen但仍被Gopher打穿，就是因为没有限制协议。在实现层面对协议做白名单，比依赖库的默认行为要可靠得多。我个人的体会是，SSRF入门容易，但要真正“会看会想”，必须把攻击链路的每一步都弄明白，而不是背几个绕过payload就觉得自己会了。真正拉开差距的是你在遇到新题目、新环境时，能不能迅速分析出限制条件到底是什么、哪一层能绕、哪一层只能硬破。基础绕过手法是必须会的，但比手法更重要的是底层的原理分析和排查思路。以后如果我再遇到新的SSRF变种题目，第一件事永远是先分清楚它限制的是什么：IP、域名、协议，还是重定向，然后再决定从哪个方向突破。这套方法论，比任何单个payload都值钱。
1. 从题目说起：SSRF到底考什么CTF圈子里流传着一句话：“没有SSRF的Web题，就像没有鸡蛋的西红柿炒蛋。”话虽然有点夸张，但确实说明SSRF在Web方向里的地位——不说是必考吧，至少是高频考点。这段时间我一直在刷某CTF平台的SSRF专题，从最简单的file://协议读文件，到绕IP限制，再到最后用Gopher打内网服务，整个链路走下来，最大的感受是：SSRF考的不是某一个单一知识点，而是“服务端请求到底能被你控制到什么程度”的综合能力。很多新手看到“SSRF”三个字母就发怵，觉得这是渗透测试或者内网攻击才用的东西，离自己很远。其实没有想象的那么玄乎。SSRF的全称是Server-Side Request Forgery，服务端请求伪造。本质就一句话：服务端接收了用户输入的URL去请求资源，但程序没有严格校验这个URL是内网还是外网、是HTTP还是其他协议，于是攻击者就能借助服务端的“手”去访问本来不该让它访问的地方。CTF里考的就是你如何在各种限制条件下，把这个“手”伸得足够长。这期实战记录，我打算按照自己从基础到Gopher的完整做题路径来展开。含金量最高的不是某个payload本身，而是每走一步时脑子里应该有的判断逻辑：它为什么能绕、为什么不能绕、换了环境之后哪些结论要推翻重来。所以这篇文章不只是给刷题的朋友做参考，对搞开发、搞运维的朋友同样有启发——很多看似不起眼的“小问题”组合在一起，就是一条完整的攻击链。1.1 一道题引出的四个问题我通关的这个系列，起步题很简单，一个Web页面，里面有个输入框，输入URL点击提交，服务端会把请求结果返回给用户。这种题型即使没接触过CTF的人也能看懂：输入http://www.example.com，页面上就会展示该网页的部分内容，输入file:///etc/passwd，有可能就直接把本地文件内容读出来了。但真要拿高分，不是读个文件就完事，而是要面对下面这四道关卡式的问题：第一，服务端可能做了IP限制。你传一个内网IP过去，比如http://127.0.0.1，它能给你拦住，让你不得不去想各种绕过手段。第二，就算能访问内网IP，你还得确定内网里到底跑了什么服务。端口靠扫，协议靠猜，这一步本质上是在“带外探测”。第三，很多服务不是HTTP协议，普通URL请求根本打不过去，这时候就得换协议，最经典的就是Gopher。第四，就算用Gopher把请求写给内网服务了，怎么构造一个有效的请求，让对方把Flag吐出来，这又是另一个层次的问题。这四个问题刚好对应SSRF从入门到进阶的四个层次。我从第一题开始挨个踩，踩到最后才发现，这几个问题不是孤立的，而是在一道题里层层递进的。1.2 SSRF题目在CTF里的典型考法先给没怎么接触过CTF的朋友简单梳理一下SSRF的常见考法，心里有个框架之后再往下看具体的绕过技巧会轻松很多。我按难度排了个序，大致是这样：难度层级常见考点典型限制条件最终目标入门任意URL请求无限制或仅外网读本地文件、探测端口初级IP地址绕过禁止内网IP用十进制/十六进制/短域名绕过中级URL解析差异过滤关键字利用协议解析差异绕过进阶重定向与协议切换限定HTTP协议利用302跳转访问内网高难Gopher协议仅允许特定协议攻击内网Redis/MySQL等非HTTP服务这个顺序基本就是我刷题的顺序。每上一个台阶，限制条件就多一层，思考方式也要跟着换。最忌讳的就是背了一堆payload以后死板套用，因为不同平台、不同语言写的后端，对URL的解析方式完全不一样，同一条绕过技巧在这一题里能用，换一道题可能就失效。所以下面我会把每种手法背后的原理讲清楚，而不是只给结论。2. 基础绕过手法的原理与实操2.1 IP与域名的那些绕法先说最常见的坑：后端直接判断你传入的URL里有没有内网IP的特征。比如你输入http://127.0.0.1:8080/flag，代码一看解析出来的host是127.0.0.1，直接拒绝。这时候最常见的思路就是换一种形式表示同一个IP。不要小看IP地址的写法，一个127.0.0.1可以被写成好几种完全不同的形式。最容易理解的是整数形式：把IPv4地址转换成一个32位整数，比如127.0.0.1对应的整数是2130706433。不少后端校验的时候只会匹配字符串特征，比如127.0.0.1、10.、192.168.这些开头，它不认识2130706433，于是请求就直接放过去了。再进阶一点可以用十六进制：0x7f000001也等价于127.0.0.1。还有八进制写法、混合写法，甚至可以用127.1这种省略形式，操作系统在某些场景下也能正确解析。这一套组合拳打下来，凡是只做字符串匹配的弱校验基本都能绕过。但这里的“绕过”是有前提的，前提是后端的HTTP库在做DNS解析和连接的时候，本身认得这些特殊格式。我实测下来，不同的语言、不同的HTTP客户端表现差异很大，有的能解析2130706433，有的不能，所以做题的时候不能想当然，一定要在靶场上多试几种写法。各种IP变体的测试优先级，我一般这么排：十六进制形式：0x7f000001整数形式：2130706433混合八进制：0177.0.0.1省略写法：127.1IPv6映射地址：[::1]、[::ffff:127.0.0.1]这里有个关键点：最终能用的形式，不完全取决于校验代码，更取决于服务端实际使用的网络库。所以遇到某个形式失败，不要急着否定它，先确认网络库的类型再说。2.2 URL解析差异与协议混用第二道关卡里，我碰到的是关键字过滤。后端检测URL里有没有127.0.0.1、localhost、file、gopher这些关键词，有就直接拦。第一种思路当然是大小写绕过，因为有些语言在做字符串过滤时是大小写敏感的，但对URL解析和DNS解析本身是大小写不敏感的。于是FILE:///etc/passwd就能绕过对file的过滤。如果大小写不好使，就该往“解析差异”方向想了。后端拿到用户输入的URL后，往往会先做一层校验，再把同一个URL交给请求库去请求。问题就出在“校验”和“请求”这两步走的不是同一套解析逻辑：校验方可能用的是一种简单的字符串匹配或正则。请求方可能是Python的requests、PHP的curl、Node的axios，各不相同。这两者之间只要有任何一个细节不一致，就能构造出“校验时不匹配、请求时匹配”的URL。比如http://127.0.0.1@evil.com这种形式，依赖某些库在解析时会取@之后的部分作为真实地址，从而把请求发往127.0.0.1。而校验方如果只是看域名部分是不是白名单，可能看到evil.com就放行了。还有更刁钻的，URL里加额外路径、分号、反斜杠、重复斜杠等，都能干扰解析。我印象最深的是反斜杠绕过：部分HTTP库在解析URL时会把\当作/处理，但一些过滤正则里写的却是标准的/。于是把http://127.0.0.1\evil.com传给服务器，它能正常请求127.0.0.1，过滤正则却以为你在访问evil.com。需要提醒的是，这种利用解析差异的绕过方式非常依赖后端环境。同一个payload在一个靶场里通了，换个平台可能全挂。原因很简单：不同语言及其HTTP库对URL标准的实现程度不一样，处理@、\、多余的/等字符的行为也不一样。所以我强烈建议，每个绕过payload在碰到实际环境时，都要先小流量验证一下，别直接上大招。2.3 302跳转与重定向跟踪绕过IP限制的另一个经典思路是“借壳上市”：找一个合法的外网域名，让它返回一个302重定向到内网地址。后端如果只校验初始URL的域名而没禁用重定向，请求就会在后面跳转时直接打向内网。这个思路为什么好用？因为很多过滤方案只盯着用户最初的输入。你输入http://example.com/redirect?target=http://127.0.0.1，后端一看example.com是白名单域名，放行；example.com返回302，Location指向http://127.0.0.1；如果请求库默认跟随重定向，那么后面这次请求就直接打到内网了。做CTF最爽的地方在于，这个“壳”不一定要找真实外网域名，你可以自己搭一个简单的服务，或者直接在靶场环境里起一个本地服务作为跳板。这里有一个小坑：如果后端请求库在跟随重定向时会带上初始请求的部分头部，可能导致请求失败；另外如果重定向目标也被同样校验了，那就此路不通。所以第一件事是先摸清后端到底跟不跟重定向，这个可以用一个可控的外部地址来看日志，看有没有收到第二次请求来确定。一个已经有很多人踩过、但我还是要再强调的细节：302跳转只能解决“IP被拦”的问题，不能解决“协议被限制”的问题。如果后端明确禁用了Gopher协议，你跳转到gopher://也照样被拦。所以做题之前先理清楚限制条件到底卡在哪一层，别把两个问题混为一谈。3. 内网探测：拿到第一手情报3.1 用请求时间盲探端口绕过限制只是第一步，真正麻烦的开始是“进去之后不知道干什么”。服务端目前能替你发起请求，但你不清楚目标内网的拓扑结构，也不知道有哪些服务开着。这时候就需要借助SSRF做内网探测了。最简单的探测方式之一是用响应时间来判断端口是否开放。原理不复杂：目标端口开放时，服务端发起TCP连接会成功，体现在响应时间上会比较快；目标端口关闭时，连接会被拒绝，或者要等超时才能返回。我们只需要构造不同的URL，让后端去请求http://127.0.0.1:{port}/，然后观察每个请求的耗时差异。在靶场环境里，我通常会扫描一批常见端口，比如3306（MySQL）、6379（Redis）、8080（常见Web服务）、9200（Elasticsearch）等。每个端口发三次请求取平均值，把耗时明显不同的端口标出来，再去逐一验证。这种盲探方式有个可能让人抓狂的点：很多靶场把“请求结果”直接渲染在了页面上，端口不通和端口开放时返回的页面内容可能都是空白，只有看响应耗时才有区分度。所以我习惯用工具辅助，手动一个个输入URL太慢了，而且人眼看着实难分辨几百毫秒的差别。用脚本边请求边记录时间是效率最高的做法。千万要注意，探测过程应当控制频率，做好延时，避免对目标服务造成压力。CTF场景内往往没问题，但如果将来你在授权测试环境里，这种操作同样要谨慎，暴力扫描很容易触发告警甚至影响业务。3.2 协议探针构造思路端口探测只能告诉你“这有个端口开着”，但开着的到底是什么服务，还得继续猜。一个可靠的思路是利用“不同服务对不同协议请求的响应特征不同”来做判断。还是拿端口6379举例。如果你让后端发起一个HTTP请求http://127.0.0.1:6379/，Redis不会返回正常的HTTP响应，它会返回一些以-ERR开头的错误信息，或者直接把连接关闭。但这个“错误信息”本身就暴露了服务类型。类似的，如果目标是MySQL的3306端口，发一个HTTP请求过去，响应会是很乱的非文本字节，这时候你在响应内容里看到协议版本号等特征，也能确认这是MySQL。更深一层，有些后端允许我们指定协议前缀，比如直接请求gopher://127.0.0.1:6379/_，那服务端就会真的发一段Gopher协议格式的数据过去。如果Redis没有设置密码，这几乎等于把钥匙递到你手里了。这里面的核心原则是：把服务端当作一个“通用协议代理”，利用它返回的响应内容来判断目标服务的类型和版本。不需要一步到位，先把范围缩到最小，再逐个击破。3.3 探测结果的分析方法我自己在刷这一系列题目时总结了一套分析方法，分三步走：第一步，先列一个“可能存在的内网服务清单”。这个清单不用太复杂，一般就是Web服务、数据库、缓存、消息队列这些常见项。像Redis、MySQL这类服务经常在CTF中被作为最终攻击目标，是因为它们本身支持文本协议，便于通过Gopher构造请求。第二步，针对每个开放端口，用不同协议去探测，并记录响应差异。比如对同一个端口分别发送HTTP、Gopher甚至Dict协议的数据，看哪个返回的内容更能揭示服务类型。有时一次探测不干净，得多试几次。第三步，把探测得到的信息与题面结合起来。CTF里的SSRF题目一般都有一个很明确的“最终目标”，比如读取某个Flag文件、写入Webshell、或者篡改某个服务配置。把内网服务摸清楚之后，攻击路径往往就浮出水面了。我踩过的一个坑是过度扫描。在一道题里，我花了大量时间把所有端口都摸了一遍，结果发现真正需要的服务就是题面里提示的那个端口。CTF讲究的是时间和拿到Flag的效率，而不是面面俱到。先把题面里的暗示读明白，再去做定点探测，而不是无头苍蝇一样漫无目的地扫。4. Gopher协议：最犀利的武器4.1 Gopher协议到底是个啥Gopher协议出现得比HTTP还早，是一种互联网早期用于信息检索的协议。放到今天，它最大的价值在于“能让服务端主动向任意TCP服务发送任意格式的数据”。这一点对于SSRF利用来说太关键了：你别管它是什么服务，只要对方是监听在TCP端口上的，你就能用Gopher把构造好的原始数据包发过去。你需要理解的一个核心概念是：Gopher协议的数据格式非常灵活，它不限定“内容必须是HTTP格式”。我们可以用Gopher去往Redis发一条SET命令，也可以往MySQL发一段认证握手包。只要目标服务能解析TCP流并做出反应，理论上都可以尝试用Gopher去打。打个比方，HTTP请求像是一个“只会说一种语言的翻译”，碰到不懂HTTP的服务就抓瞎。而Gopher像是一个“原始字节传送带”，它不在乎谁在说话，只管把货送到。因为这一特性，Gopher成为SSRF攻击链路上从“能访问”到“能利用”之间最重要的一座桥。不过，使用Gopher也有一个前提：服务端发起请求的代码必须允许使用这个协议。很多后端库默认只允许HTTP/HTTPS，不让用gopher://这种前缀。所以当你发现URL里可以指定协议但被过滤掉gopher关键词时，第一反应应该是做编码绕过、参数污染，而不是直接认为“这题考的不是Gopher”。4.2 构造Gopher请求的注意事项构造Gopher请求时，第一件要做的事是URL编码。因为Gopher数据从格式上会被拼接到URL的路径部分，里面一旦出现?、&、%、空格、换行等特殊字符，就会干扰URL的解析，所以必须把整个数据块做一次URL编码。一个经典的格式是：gopher://127.0.0.1:6379/_数据内容_之后的部分就是你要发送的原始数据。如果是Redis命令，通常是一行一条命令，命令之间用\r\n分隔，多行之间也用\r\n分隔。然后把这整段内容做一次URL编码，再拼接到gopher://后面。我踩过的坑主要在两个地方。一个是换行符的处理。构造Redis命令时，很多人会直接用\n，结果命令在服务端解析时出错，因为Redis协议要求的是\r\n，两个字符缺一不可。另一个是重复编码。直接把已经编码过一次的数据再编码一次，会导致协议原文被破坏，服务端收到的不是你想发的命令。为了不在这类细节上反复折腾，我的经验是：先写一个最小的Python脚本，把要发送的协议数据打印出来看一眼，确认编码前与编码后的差异，再决定提交什么内容。肉眼确认一遍往往比URL编码器自动生成的结果更靠谱。4.3 拿Redis开刀的完整链路在CTF题目里，Redis几乎是Gopher攻击最经典的目标。原因有三点：默认监听在6379端口；经常以无认证方式运行；支持的命令集足够简单，一条SET、一条CONFIG SET就能做很多事。在一次靶场练习中，我的思路先是确定6379端口开放，然后用Gopher协议发了一条INFO命令，成功收到Redis的版本信息。确认无认证后，我尝试写入一个WebShell或者改写配置。构造Redis命令时，最需要注意的是批量协议格式。比如SET命令：*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n这里*3表示后面有三个参数，$3表示接下来的参数长度是3，依次类推。很多新手开始接触时会觉得这种格式“太绕了”，实际上这是Redis客户端与服务端通信的标准协议，抓包看一眼就明白了。用Gopher去打Redis，本质上就是替你手工把这个协议包拼出来。最后一步是把命令编码后作为Gopher请求体发送。如果成功，Redis里就会多出一条数据，接下来就根据题目要求去做对应操作。这里必须强调一点：以上所有操作都只适用于CTF靶场和授权测试环境，不能拿到真实生产环境里搞破坏。真实环境中的Redis如果暴露在外网，本身就是高危配置，务必做好访问控制、认证和网络隔离，而不是等别人来“教学”。5. 实战题目拆解：从过关到漏洞利用5.1 题目环境与信息收集我拿一道比较综合的题目来复盘整体思路。这道题给了一个提交URL的输入接口，提示业务方需要“获取网页快照”。它的限制条件是：请求必须从服务器发出，且只允许访问HTTP和HTTPS协议，IP地址不能是内网IP。看起来条件挺多，但实际上整个攻击链是这样的：第一步，提交一个外网正常的URL，比如某个我控制的服务地址，确认服务端能够发请求并把响应返回。第二步，尝试提交file:///etc/passwd，看协议是否被限制。如果被限制，就要考虑用302跳转或URL解析差异绕过，因为HTTP请求库通常不允许file协议。第三步，观察后端是否跟随重定向。用一个可控的外部服务器返回302跳转到http://127.0.0.1:80/，如果页面返回了本地Web服务的内容，说明重定向这条路线通了。第四步，用302跳转结合Gopher去访问内网的服务，做端口探测与服务识别。这个过程的每一步都可以在题面上找到“为什么这样设计”的线索。比如如果题目明明限制了协议却仍开放了重定向能力，那几乎就是明示你可以用跳板绕过协议限制。5.2 绕过过程的重点记录我在做这一题时的真实顺序是，先试了试http://127.0.0.1:8080/flag，直接提示“内网地址禁止访问”。然后我把IP改成整数形式http://2130706433:8080/flag，结果还是提示禁止。这说明校验不是简单字符串匹配，可能是解析后的IP也在黑名单里。于是我转向302跳转方案。自己在本地搭了一个简单的跳板服务，返回一个302响应，Location是http://127.0.0.1:80/。提交给靶场后，页面上出现了本地Web服务的默认页面。这个结果证明两件事：第一，后端跟随了重定向；第二，重定向目标不再被二次校验。有了这两条信息，后面再拿Gopher去打其他端口，就只是工程量的问题了。有个印象很深的细节：第一次构造302跳板时，我在Location里写的是http://localhost:80/，结果请求失败了，换成http://127.0.0.1:80/才成功。推测是后端对localhost做了额外的域名过滤。这种小坑看起来不起眼，实际排查起来很浪费时间，所以Debug时建议同一类型的域名、IP变体都试一轮，不要把宝押在一个写法上。5.3 最终利用与Flag获取探测内网服务时，我扫到6379端口开放。回到题面，它提到业务方“会缓存访问的结果”，这几乎就是在暗示存在Redis。于是构造Gopher请求，发送Redis命令，成功写入数据后，再回到首页读取，最终拿到Flag。整个过程真正困难的不是“最后一步的payload”，而是前面对各种限制条件的一次次试探。我甚至觉得SSRF题目做题到最后，拼的是“耐心”和“系统性”。一个请求失败了，到底是校验拦截，还是网络不通，还是协议不支持，要能很快判断出来；判断不出来，就用替代方案交叉验证。像我这次遇到的302跳板，如果本地测试时没有先在外网可控地址上确认返回码，后面整个链条都走不下去。这类题还有一个特别突出的人为因素：题目环境往往会预留大量的“线索注释”，包括代码片段、提示信息等。做题前先把所有线索读清楚，往往能少走一半弯路。比如题面里写了一句“业务方希望给每个网页生成快照”，这意味着什么？意味着后端一定有一个“根据URL发起请求并保存内容”的过程，这本身就是SSRF的典型成因。6. 高频踩坑点与排查思路6.1 请求总是失败？先查这三个我做SSRF系列踩过的坑不少，总结下来最常出问题的三个点，分别是URL编码、协议白名单、重定向策略。很多请求失败并不是因为思路不对，而是因为在这些基础细节上翻车了。先说URL编码。Gopher请求中只要包含?、&、%、空格、#等字符，就必须编码，否则URL解析时会被切分。新手最容易出错的地方是忘记对?编码，导致Gopher数据里的参数被当成URL的query string。我的建议是，构造完请求后先用工具解码一遍，确认最终发送的字节和预期一致。这比直接在页面上硬试高效得多。再说协议白名单。很多后端允许http与https，但对gopher、dict、file有限制。遇到这种情况，不能直接断言“这题打不了”，而是先看白名单是怎么实现的。如果只做了字符串前缀匹配，里可能藏有大小写、双重编码、换行绕过等空间。如果白名单真的锁得很死，还可以考虑302跳转带出来，因为重定向目标有时候不会再做一次协议校验。最后是重定向策略。有些请求库默认不跟随重定向，有些默认跟随，还有一些需要额外的参数才能支持。这一点直接决定302路线是否可用。一个实用的排查办法是：自己控制一个外部服务，让它返回302，然后在服务端日志里看有没有第二次请求过来。有，说明跟；没有，说明这条路被切断了。6.2 编码与协议细节的常见误区还有一个容易让人困惑的问题是“双重编码”。很多人会在构造Gopher payload时，先手动把数据做了一遍URL编码，再交给框架做一次自动编码，结果发出去的数据完全变形。拿Redis命令举例，一条SET mykey myvalue，编码前的原始字节是SET mykey myvalue\r\n，编码后变成SET%20mykey%20myvalue%0d%0a，再次编码就不是同一个东西了。在实战中，我最推荐的流程是：先用Python或在线工具把原始数据转换成URL编码形式，然后在提交时检查浏览器网络请求里的最终URL。如果发现URL里的%符号又被编码成了%25，那说明框架自动编码了一次，需要调整策略。另外，Redis协议的裸CRLF也是一大坑。有些编辑器或者手写脚本时，\r\n会被悄悄替换成\n，直接把协议包弄坏。用字节序列打印工具确认一下，能把这类问题扼杀在摇篮里。协议细节虽小，一旦出错，往往表现为“请求发出去了但服务端没有任何反应”，排查起来十分吃力。所以我的习惯是，每构造一个新的payload，最先做的不是提交到靶场，而是本地起一个简单的TCP监听服务，把Gopher协议实际发送的字节原样收下来看一眼。确认字节对了再上靶场，成功率会高出一大截。7. 从攻击视角回到防御视角聊了这么多攻击和利用技巧，最后想花点篇幅讲述防御端的思考。因为只懂进攻不懂防御，很容易让人觉得CTF打得好但在真实业务里使不上劲。反过来，理解了攻击者的思路，才能真正理解为什么SSRF这么危险，以及防御时要关注哪些点。SSRF的根因是“服务端发起了用户可控的请求”。所以最简单有效的防御是尽量不让用户直接控制目标URL。如果业务确实需要接受URL，那就必须做白名单校验：协议只能允许HTTP/HTTPS，IP解析结果必须经过二次确认，域名解析后如果是内网地址就直接拒绝。第二个关键点是重定向。很多防御方案只校验第一跳，结果攻击者用一个外网302就打进去了。因此更完善的方案是，在跟随重定向的每一跳上都执行同样的校验逻辑，而不是只校验初始URL。同时推荐默认关闭自动跟随重定向的选项，定点打开才更安全。第三个点是协议层控制。如果后端通过类似Requests这样的库发起请求，务必确认库支持的协议范围。很多后端代码里直接写死urlopen但仍被Gopher打穿，就是因为没有限制协议。在实现层面对协议做白名单，比依赖库的默认行为要可靠得多。我个人的体会是，SSRF入门容易，但要真正“会看会想”，必须把攻击链路的每一步都弄明白，而不是背几个绕过payload就觉得自己会了。真正拉开差距的是你在遇到新题目、新环境时，能不能迅速分析出限制条件到底是什么、哪一层能绕、哪一层只能硬破。基础绕过手法是必须会的，但比手法更重要的是底层的原理分析和排查思路。以后如果我再遇到新的SSRF变种题目，第一件事永远是先分清楚它限制的是什么：IP、域名、协议，还是重定向，然后再决定从哪个方向突破。这套方法论，比任何单个payload都值钱。