1. 从一道靶场题看SSRF的真实攻击链
fakebook这道题在攻防世界的 Web 进阶区里算是比较经典的一个存在，很多人第一次接触 SSRF（Server-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、2130706433（127.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 | 读取本地文件 | 读源码、读配置、读 flag |
dict | 探测端口和服务 | 判断端口开放、获取 banner |
gopher | 构造任意 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.com@127.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是 CRLF，Redis 协议要求命令以 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 就是一个很好的起点，建议你亲手复现一遍，把每个步骤都走通，比看十篇文章都管用。
