【实战】某H5炸金花游戏站的 SSRF探测内网与 Redis未授权

一、故事背景

这是对某H5炸金花游戏站的一次授权渗透测试。目标系统免下载的 H5 版炸金花游戏，纯网页即点即玩，流量主要来自社交裂变。客户重点关注服务器端的安全，因为其业务高度依赖后端服务。我在拿到授权后，把测试重点放在了 SSRF（服务端请求伪造）这类能直接攻击内网服务的漏洞上。SSRF 之所以危险，是因为它能让攻击者借服务器之手访问内网，绕过防火墙限制。

二、信息收集

信息收集阶段，我在目标站点上发现了一个"远程图片加载"功能，用户提交一个图片 URL，服务器会下载该图片并展示。这个功能的 URL 参数显然是用户可控的，是典型的 SSRF 高发点。我先提交了一个正常的外网图片 URL，确认功能正常，然后开始测试能否访问内网地址。我构造了 http://127.0.0.1/ 和 http://127.0.0.1:6379/ 等请求，观察返回差异。

三、漏洞发现

测试结果显示，当提交 http://127.0.0.1:6379/ 时，返回了 Redis 特有的错误信息"-ERR unknown command"，这说明服务器能访问本机的 Redis 服务，且该 Redis 未设置认证密码。这是一个典型的 SSRF + 内网 Redis 未授权访问的组合漏洞。我进一步测试了其他内网端口，如 6379、27017、9200 等，绘制出了内网服务的分布图。

四、漏洞利用

确认 Redis 未授权后，我开始构造攻击载荷。Redis 可以通过 CONFIG SET 命令修改持久化路径和文件名，将恶意内容写入系统文件。我利用 SSRF 的 gopher 协议来发送经过编码的 Redis 命令，目标是向 /var/spool/cron 目录写入一个计划任务文件，让服务器定时执行反弹 shell 脚本。整个 payload 需要精心构造 gopher 请求体，将 Redis 命令按 RESP 协议编码。

五、权限获取

我构造好 gopher payload 后，通过 SSRF 提交给服务器。攻击命令包括：设置 dir 为 /var/spool/cron、设置 dbfilename 为 root、写入包含反弹 shell 的计划任务内容、执行 save 持久化。我的 VPS 上提前用 nc 监听了 7777 端口。payload 执行后，等待约一分钟，VPS 上成功收到了来自目标服务器的反弹连接，且是 root 权限，因为 Redis 是以 root 身份运行的。

六、复盘总结

这次渗透的关键教训是：SSRF 和未授权 Redis 的组合危害极大。修复建议：第一，SSRF 必须严格限制目标协议和地址，禁止访问内网网段，只允许 http/https 协议访问白名单域名；第二，Redis 必须绑定 127.0.0.1 并设置强密码，禁止以 root 身份运行；第三，对 SSRF 请求的响应做过滤，防止回显内网信息；第四，服务器应开启防火墙，即使内网服务也要限制来源。

本文为授权安全评估实录，目标均已脱敏（IP 为文档保留段），仅用于安全研究与学习交流。