文章总结： 文章分享了三个云安全与SSRF漏洞挖掘实战案例。首个利用Nginx路径解析特性与预签名机制缺陷，构造特殊路径绕过路由限制实现云存储桶列取。次例针对SSO认证逻辑，通过控制认证服务器IP篡改响应数据，利用信任链缺陷实现任意用户登录。末例通过分析登录响应中的冗余字段发现架构痕迹，替换Host头绕过URL白名单校验实现全回显SSRF。内容展示了深入的逻辑分析与绕过技巧，具有较高实战价值。 综合评分： 92 文章分类： 云安全,WEB安全,渗透测试,实战经验,漏洞分析

云安全与SSRF漏洞挖掘的实战启示

原创

雨滴梦呓 雨滴梦呓

雨滴梦呓

2026年1月12日 18:01 河北

受邀参加2025年度颁奖典礼，运营同学说其中有交流会的环节，可以提前准备几个挖过的漏洞讲一讲，于是拿几个有意思的漏洞跟各位师傅交流一下～

文章内容速览~云存储越权：利用Nginx路径解析特性，突破预签名限制实现存储桶列取SSRF劫持认证链：控制SSO服务器IP→篡改uid响应→业务端信任链污染致任意登录域名校验逻辑绕过：复用登录响应冗余domain字段替换Host，突破URL白名单实现全回显SSRF

利用云存储预签名和Nginx路径解析漏洞实现存储桶列目录

Nginx路径解析与路由顺序缺陷导致的预签名越权

功能场景：

一个图片上传功能点

上传后返回了一个URL

访问URL后302跳转到了存储桶地址

一眼预签名，想要预签名到根目录实现列桶

直接GET /返回的是首页内容

发现后端是nginx

提出问题

1. 为什么img路径可以预签名
2. 如果想要预签名到根目录需要什么条件

首先想到的就是路由

nginx中的路由转发

然后我尝试了常见的路径名称

发现img和file都可以进行预签名

但是想要使用../常规的预签名列桶方式进行列桶发现不会走到预签名的接口去

/img/ =>/桶名/img/?signstring/img/../ => /index?????? => /桶名/?signstring

为什么呢

查询文档发现nginx会先解析../再进行路由转发

那么如果我想预签名到存储桶的根目录需要实现什么条件呢

我需要让nginx在进行路由转发的时候匹配到img或者file路径

然后我还需要预签名的接口可以解析我的../

很幸运 Nginx处理请求时它会无视了#后面的所有东西

而巧合的是后端会对../进行解析

于是最终利用成功的poc是这样的

/img/#/../../../[BucketName]/

通过无回显SSRF控制认证服务器实现任意用户登录

信任链传递未二次验证导致的SSRF认证链污染

功能场景

sso认证，提交的参数中有个serverip

URL可控=>SSRF

测试无回显SSRF 成功

根据业务逻辑分析这是个认证的接口

而且是SSO认证 那这个serverip很有可能就是控制认证服务器的

通过dnslog收到的请求看下

猜想这就是sso服务器的地址

通过dnslog获取到业务服务器往认证服务器发送的信息

这时候需要确认一个问题就是现在认证接口返回的用户凭证是由sso服务器返回的，还是将sso服务器返回后的信息二次处理的

如果是将sso服务器返回后的信息二次处理生成的凭证 那就可以尝试控制认证服务器的返回值实现任意用户登录

所以需要先看sso服务器返回了什么内容

将host换成原本的serverip

从sso的返回信息中未发现认证接口返回的usersign

但是返回信息中有一个uid和认证接口返回qid是一样的

于是猜想业务服务器是将当前用户凭证发送给sso服务器查询用户信息

然后业务服务器再将认证服务器返回的用户信息中的id生成最终认证凭证

用户再通过这个认证凭证访问业务2

最终实现单点登录的免登访问其他业务

但是由于sso服务器可控

就导致了可以控制返回的用户id

这个用户id也存在缺陷一是可以遍历 而是从其他接口可获取大量用户id

于是造成任意用户登录

域名校验旁路绕过实现全回显SSRF

冗余参数暴露系统架构痕迹导致域名校验旁路

功能场景

导出pdf，提交的参数中存在一个url参数

通过测试发现json中url参数必须以特定的url开头

https://aaa.bbb.com/

如果能绕过url的话大概率可以全回显SSRF

尝试使用子域名、@、@%2f、混淆域名等等绕过方式都无法绕过正则

写死了必须以这个域名开头

从单个数据包无法绕过后开始研究整个流程

发现这个域名是通过单点登录进入的

登录后返回token 后续通过token进行认证

但是这个登录的返回包很奇怪

返回token的同时还返回了一个毫不相干的domain

并且在后面的流程中都没有用到这个域名

但是为什么会返回呢

这时候就有了一个大胆猜想

这个返回的domain会不会跟当前业务交互的域名使用的相同的后端

是不是当前业务直接复制了这个返回domain的后端

于是我做了一个操作

将导出数据包中的host改为这个返回的domain 其他保持不变 包括token

然后将url更改内SSRF的攻击地址 无任何校验直接全回显

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：雨滴梦呓 雨滴梦呓 雨滴梦呓《云安全与SSRF漏洞挖掘的实战启示》