1. 从一道靶场题看SSRF的真实攻击链fakebook这道题在攻防世界的 Web 进阶区里算是比较经典的一个存在很多人第一次接触 SSRFServer-Side Request Forgery服务端请求伪造就是从这个靶场开始的。它的核心逻辑并不复杂一个模拟的社交平台提供了用户注册、登录、发布信息、查看他人主页等功能但在某个不起眼的接口里服务端会拿着用户可控的 URL 去发起请求最终导致攻击者可以借助服务器的身份去访问内网资源拿到 flag。我之所以想单独拿这道题出来聊是因为它几乎涵盖了 SSRF 从发现到利用的完整链路信息收集、源码泄露、参数注入、协议利用、内网探测、数据外带。你在真实项目里遇到的 SSRF 漏洞大概率也是这个套路只是入口更隐蔽、过滤更严格而已。这篇文章我会按照实际做题的顺序把每一步的思考过程、踩过的坑、以及可以复用的技巧都摊开来讲适合刚接触 SSRF 的新手也适合想系统梳理一遍利用链的老手。需要提前说明的是本文所有操作均在本地搭建的靶场环境中完成目的是理解漏洞原理、提升防御意识请勿将相关技术用于任何未经授权的场景。2. 信息收集与源码泄露的突破口2.1 初识 fakebook功能面与攻击面分析打开靶场首页你会看到一个类似早期社交网站的东西注册、登录、发帖、查看用户主页。页面设计很朴素功能也不多但越是这种“看起来没什么东西”的站点越需要耐心去翻。我一般拿到一个 Web 靶场会先做三件事用浏览器开发者工具看一遍所有请求尤其是 XHR 请求看看有没有隐藏的 API 接口手动翻一遍robots.txt、sitemap.xml、www.zip、backup.zip这类常见文件注册一个账号把每个功能点都点一遍观察 URL 参数的变化规律fakebook这道题的关键突破口就在第二步。访问robots.txt你会发现里面写了Disallow: /user.php.bak这个.bak后缀就是典型的源码备份文件泄露。直接访问/user.php.bak浏览器会下载一个 PHP 源文件这就是整个攻击链的起点。提示源码备份文件泄露是 CTF 和真实渗透中都极其常见的入口常见后缀包括.bak、.swp、.old、.zip、.tar.gz、~等。养成拿到站点先扫一遍备份文件的习惯能省很多事。2.2 审计 user.php.bak找到 SSRF 注入点下载下来的user.php.bak内容大致是这样的结构我做了简化保留核心逻辑?php class UserInfo { public $name; public $age; public $blog; public function __construct($name, $age, $blog) { $this-name $name; $this-age $age; $this-blog $blog; } public function getBlogContents() { return $this-get($this-blog); } public function get($url) { $ch curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $output curl_exec($ch); curl_close($ch); return $output; } }看到curl_exec配合用户可控的$url基本可以确定这里就是 SSRF 的注入点。服务端会拿着用户填写的 blog 地址去发起请求然后把返回内容展示出来。这意味着我们可以让服务器去访问任意地址包括内网服务。但这里有个前提$blog的值是从哪里来的继续往下看源码会发现用户注册时有一个blog字段登录后可以在个人信息页修改。也就是说我们注册时填的 blog 地址会被存进数据库然后在某个页面被getBlogContents()调用。2.3 注册账号并确认注入点注册一个账号blog 字段先随便填一个http://example.com登录后进入个人信息页你会看到页面尝试加载这个 blog 的内容。如果填的是一个不存在的域名页面会卡一下然后显示空白或者报错这说明服务端确实在发起请求。把 blog 改成http://127.0.0.1/如果返回了本机 Web 服务的首页内容那就实锤了 SSRF。这一步是整个利用链的验证环节确认了注入点存在后面才有得玩。注意有些环境里127.0.0.1会被过滤可以尝试0.0.0.0、127.1、2130706433127.0.0.1 的十进制表示等绕过方式。这道题没有做过滤直接127.0.0.1就能用。3. SSRF 利用链的核心细节与协议技巧3.1 为什么 SSRF 危害这么大从“请求伪造”说起很多人对 SSRF 的理解停留在“让服务器帮我访问一个网址”觉得这没什么大不了的。但实际上SSRF 的本质是权限边界的突破。打个比方你是一个访客站在公司前台前台有一部内线电话。正常情况下你只能打给前台但如果你能骗前台帮你拨内线分机你就能联系到公司内部任何一个部门。SSRF 就是那个“骗前台拨号”的过程——服务器处于内网环境中它能访问到很多外部访问不到的地址比如127.0.0.1上的管理后台、192.168.x.x网段的其他服务、云环境里的元数据接口等等。在fakebook这道题里flag 就藏在服务器的某个内网服务里我们没法直接访问但可以通过 SSRF 让服务器自己去读然后把内容返回给我们。3.2 协议利用file、dict、gopher 的适用场景SSRF 能用的协议不止 HTTP 一种不同协议在不同场景下有不同的妙用。我把常见的几种整理成表格方便对照协议用途典型场景http/https访问 Web 服务探测内网 Web、读取接口返回file读取本地文件读源码、读配置、读 flagdict探测端口和服务判断端口开放、获取 bannergopher构造任意 TCP 数据包攻击内网 Redis、MySQL 等ftp访问 FTP 服务较少用特定场景在fakebook里最直接的思路是用file://协议去读本地文件。比如把 blog 改成file:///etc/passwd如果页面返回了 passwd 的内容说明file协议可用。但 flag 通常不会放在这么明显的位置需要结合目录结构去猜。我实际做的时候先试了file:///flag、file:///flag.txt、file:///var/www/html/flag.php这几个常见路径最后在某个路径下读到了 flag。这里的关键是不要只盯着 Web 根目录/flag、/root/flag、/tmp/flag都是高频位置。3.3 内网探测用 dict 协议扫端口如果file协议被禁用了或者 flag 不在文件系统里那就需要转向内网探测。dict://协议可以用来判断某个端口是否开放dict://127.0.0.1:6379/ dict://127.0.0.1:3306/ dict://127.0.0.1:8080/如果端口开放dict协议会返回服务的 banner 信息如果端口关闭会返回连接拒绝的错误。通过这种方式可以快速摸清内网有哪些服务在跑。在fakebook的环境里我扫到过一个内部端口跑着简单的 HTTP 服务直接访问http://127.0.0.1:端口/就能拿到 flag。这也是 SSRF 最经典的利用方式之一。实操心得扫端口的时候不要一次性发太多请求有些环境有频率限制或者 WAF容易被封 IP。建议先扫常见端口80、443、6379、3306、8080、8888再根据结果决定要不要扩大范围。3.4 绕过过滤的几种思路虽然fakebook这道题没有做严格的过滤但真实场景里 SSRF 的防御手段五花八门这里顺带聊几种常见的绕过思路算是给后续遇到更难的题做个铺垫。IP 地址变形127.0.0.1可以写成127.1、0x7f000001、2130706433、0177.0.0.1等多种形式很多基于字符串匹配的过滤器会被绕过。DNS 重绑定用一个域名先解析到外部 IP 通过校验再快速切换解析到内网 IP利用校验和实际请求之间的时间差。URL 解析歧义利用不同语言、不同库对 URL 解析的差异比如http://evil.com127.0.0.1/在某些解析器里会被认为是访问127.0.0.1。302 跳转如果服务端只校验初始 URL可以让自己控制的服务器返回一个 302 跳转到内网地址服务端跟随跳转就绕过了校验。这些技巧在fakebook里用不上但它们是 SSRF 实战的核心武器库值得单独花时间研究。4. 完整实操流程与关键环节复现4.1 环境准备与工具清单在开始复现之前先把需要的工具列一下浏览器Chrome 或 Firefox带开发者工具Burp Suite 或类似的抓包工具用于修改请求参数一个文本编辑器看源码用可选的目录扫描工具如 dirsearch用于发现备份文件靶场环境是本地搭建的不需要额外配置网络。如果你是在线靶场直接访问提供的地址即可。4.2 第一步发现备份文件访问http://靶场地址/robots.txt内容如下User-agent: * Disallow: /user.php.bak直接访问http://靶场地址/user.php.bak浏览器会下载文件。用文本编辑器打开找到getBlogContents和get方法确认curl_exec的存在。这一步的意图很明确robots.txt 是站点主动告诉爬虫哪些目录不要爬但反过来它也暴露了敏感路径。很多开发者会把备份文件、管理后台路径写在 robots.txt 里以为这样能藏住实际上等于给攻击者指路。4.3 第二步注册账号并定位 blog 字段注册页面填写用户名、密码、年龄、blog 地址。blog 地址先填http://example.com注册成功后登录。进入个人信息页观察页面加载行为。如果页面有明显的延迟说明服务端在请求 blog 地址。用 Burp 抓包找到更新个人信息的请求确认blog参数会被提交到服务端。这里有个细节有些题目的 blog 字段只在注册时生效有些则可以在个人信息页随时修改。fakebook是后者修改后立即生效方便我们反复测试。4.4 第三步验证 SSRF 并读取本地文件把 blog 地址改成http://127.0.0.1/保存后刷新个人信息页。如果页面显示了本机 Web 服务的首页内容SSRF 验证成功。接下来尝试file://协议file:///etc/passwd如果返回了 passwd 内容说明file协议可用。然后开始猜 flag 路径file:///flag file:///flag.txt file:///var/www/html/flag.php file:///root/flag我实际测试时file:///flag直接返回了 flag 内容。这一步的关键是耐心尝试不同路径不要试了两三个就放弃。4.5 第四步内网端口探测备用方案如果file协议被禁用就转向内网探测。把 blog 地址改成dict://127.0.0.1:6379/如果返回 Redis 的 banner类似-ERR unknown command说明 6379 端口开放。然后可以尝试用gopher协议构造 Redis 命令写入 WebShell 或者读取数据。gopher协议的格式比较特殊需要把 TCP 数据包按照 URL 编码规则转换。比如要发送INFO命令给 Redis构造出来的 URL 大致是gopher://127.0.0.1:6379/_INFO%0d%0a这里的%0d%0a是 CRLFRedis 协议要求命令以 CRLF 结尾。如果要发送多条命令继续拼接即可。注意gopher协议在很多 PHP 版本里默认不支持需要 curl 编译时开启了 gopher 支持。如果测试发现 gopher 不可用可以尝试用dict协议配合其他技巧或者转向 HTTP 协议探测内网 Web 服务。4.6 第五步数据外带与 flag 获取无论用哪种方式最终目的都是让服务器把 flag 内容返回给我们。file协议直接返回文件内容http协议返回内网服务的响应gopher协议需要构造能回显的命令。在fakebook里最简单的方式就是file:///flag一步到位。如果遇到更复杂的环境可能需要结合 DNSLog 或者 HTTP 请求把数据外带到自己控制的服务器上。5. 常见问题与排查技巧实录5.1 请求没有返回内容怎么办这是最常见的问题。可能的原因有几个目标地址不可达内网服务没启动或者端口不对协议不支持PHP 的 curl 扩展没有编译对应协议超时设置太短服务端设置了CURLOPT_TIMEOUT请求还没完成就断了返回内容被过滤服务端对返回内容做了关键字过滤排查思路先用http://127.0.0.1/确认基本的 SSRF 可用再逐步替换协议和地址。如果http可用但file不可用说明协议被禁用了需要换思路。5.2 常见问题速查表问题现象可能原因解决方法页面一直加载中目标地址不可达或超时换地址或缩短超时时间返回空白服务端过滤了返回内容尝试编码绕过或换协议file协议报错协议被禁用改用http或dict探测gopher不可用curl 未编译 gopher 支持改用dict或http端口扫描全部超时防火墙拦截尝试常见端口或换探测方式flag 路径猜不到路径不常见读源码找线索或扫目录5.3 独家避坑技巧技巧一先读源码再猜路径。很多人拿到 SSRF 就急着扫端口、猜 flag 路径其实先读一遍源码往往能找到 flag 的存放位置或者提示。fakebook的源码里虽然没有直接写 flag 路径但通过目录结构可以推断出 Web 根目录缩小猜测范围。技巧二用php://filter读源码。如果file协议可用但目标文件是 PHP 文件直接读会被执行。这时候可以用php://filter/convert.base64-encode/resource文件路径把文件内容 Base64 编码后读出来避免被解析。技巧三注意 URL 编码。有些环境会对 URL 做一次解码如果 payload 里有特殊字符需要二次编码。比如gopher协议里的%0d%0a在某些环境下需要写成%250d%250a。技巧四善用 Burp 的 Repeater。修改 blog 地址后不需要每次都刷新页面直接用 Burp 重放更新请求观察响应内容效率高很多。技巧五记录每次尝试的结果。SSRF 利用往往需要尝试很多次把每次的 payload 和响应结果记下来避免重复劳动也方便回溯。6. 从靶场到实战SSRF 防御的思考做完这道题反过来想想防御方应该怎么做其实收获更大。第一不要信任用户输入的 URL。如果业务确实需要让用户提交 URL必须做严格的白名单校验只允许特定的域名和协议。第二禁用不必要的协议。curl 支持很多协议但业务通常只需要 HTTP/HTTPS。在curl_setopt里设置CURLOPT_PROTOCOLS限制协议范围能挡掉大部分利用方式。第三限制内网访问。在服务器层面配置防火墙规则禁止 Web 服务访问内网敏感网段和元数据接口。第四不要回显请求结果。如果业务不需要把请求内容展示给用户就不要返回减少信息泄露。第五做好错误处理。不要直接把 curl 的错误信息返回给用户错误信息里可能包含内网地址、端口等敏感信息。这道题的价值不在于拿到 flag 本身而在于它把 SSRF 的完整链路浓缩在一个小环境里让你能快速理解漏洞的成因和利用方式。实际工作中遇到的 SSRF 可能更隐蔽但核心逻辑是一样的找到用户可控的 URL 参数确认服务端会发起请求然后利用协议和内网访问能力获取敏感数据。我个人在做这类题时的习惯是每道题做完都写一份简短的复盘笔记记录注入点位置、利用的协议、绕过的过滤、以及最终获取 flag 的方式。积累多了之后再遇到类似的漏洞基本能条件反射地想到几种利用思路。这道fakebook的 SSRF 就是一个很好的起点建议你亲手复现一遍把每个步骤都走通比看十篇文章都管用。
