pikachu平台 ssrf漏洞

打开pikachu靶场，SSRF漏洞就明晃晃挂在菜单里。这个漏洞的原理说白了就一句话：服务器端接收了用户提供的URL，然后替用户去请求这个地址，却没做任何过滤。

我拿实验环境试了一下。输入一个内网地址，比如http://127.0.0.1:8080/pikachu/ssrf/curl_exec.php?url=http://127.0.0.1/pikachu/vul/ssrf/ssrf_info.php——注意看，我让服务器自己请求自己。返回的页面里居然直接显示了内网服务的响应内容。这等于什么？等于你给了服务器一张“万能门禁卡”，它拿着这张卡替你打开了内网所有房间的门。

更麻烦的是，pikachu这个靶场里还提供了file_get_contents和fsockopen两种方式的SSRF演示。用file_get_contents那个接口，我甚至能读取服务器本地文件。把url参数改成file:///etc/passwd，密码文件内容就赤裸裸地躺在响应里。这不是玩笑，这是真实存在的攻击路径。

现实中这类漏洞有多危险？2019年Capital One数据泄露事件，就是攻击者利用SSRF拿到了AWS元数据服务的访问权限，最终窃取了1亿多人的信用信息。元数据服务是什么？就是云服务器上那个169.254.169.254地址，里面存着云账号的临时密钥。SSRF一旦能打到这个地址，等于直接拿到了云环境的“保险柜钥匙”。

pikachu平台把这个漏洞单独拎出来训练，用意很明显——很多开发者根本意识不到“让服务器去访问一个URL”这个功能会出问题。他们觉得，我只是转发个请求而已，又不直接执行命令，能有什么风险？风险就在“转发”这个动作本身。服务器成了你的代理，它带着内网信任的IP身份去访问内部资源，那些只有内网能访问的服务，比如管理后台、Redis、数据库，全都暴露了。

我见过一些真实系统的代码，他们把用户输入的URL直接拼到curl命令里，甚至连协议都没限制。这种代码放在公网，就像把自家后门钥匙挂在门口。防御其实不难，最基础的做法就是白名单校验，只允许访问指定域名或IP段。再严格一点，禁用重定向，因为很多SSRF绕过就是靠重定向跳转到内网地址。还有一点容易被忽略——DNS解析校验。你校验了域名是安全的，但攻击者可以让域名解析到内网IP，照样绕过。

pikachu的SSRF模块还配了curl、file_get_contents、fsockopen三种不同实现方式，这挺有意思。三种方法触发漏洞的条件略有不同，但核心问题都一样——没有对目标地址做任何限制。训练完你会发现，SSRF的利用手法比想象中灵活得多。有时候URL里加个@符号就能绕过滤，有时候用短地址跳转就能骗过校验。这不是死板的漏洞，它更像一个“跳板”，利用价值取决于内网里有什么。

所以别小看这个靶场练习。它模拟的攻击场景，和真实世界里的渗透测试几乎一模一样。你在这里练熟了，遇到实际系统里类似的参数，一眼就能嗅出风险。