标签：厂商 SSRF 接口 content FUZZ type 赏金

0x01 对目录批量FUZZ，发现一处隐蔽接口

挖某大厂已经挖了快两个周了，期间因为公司业务比较繁忙，最近一直没挖。

但是一直在用ffuf挂着字典对厂商资产进行批量目录扫描，今天上服务器看了下扫描结果，就出货了

接口地址为：https://xxx.xxxx.com/xxxx/start

我们直接对其进行访问

发现该接口给我们提供了一些可以使用的接口链接

我们逐个测试拼接接口后，发现一个名为face_xxxx的接口有戏

0x02 FUZZ传参格式+参数

访问接口，提示Method Not Allow，405错误，那么很显然，我们得换POST传参

POST随便传个参过去，发现接口提示"Request error, content-type was unsupported"

很好，继续FUZZ content-type header(记得把payload_processing自动编码给关掉)

FUZZ出来application/json的content-type头可用，那么很简单了，构造JSON数据，继续FUZZ JSON数据参数

0x03 SSRF无脑到手

参数为image_url，稍有经验的朋友就可以借此判断出，很可能这个参数是加载远程图片的

直接进行SSRF测试

服务器收到了请求，经测试gopher，dict，http等常规协议都可以使用~

之前收集了不少该厂商内网redis的ip和密码，借用本处SSRF完全可以批量对内网Redis进行密码喷洒+反弹shell，但厂商的测试守则明确规定是不允许进行内网渗透的，那就只能点到为止了~

0x04 后言

渗透之路千万条，厂商授权第一条，如果授权没搞好，监狱牢饭吃到饱~

标签：厂商,SSRF,接口,content,FUZZ,type,赏金
来源： https://www.cnblogs.com/J0o1ey/p/15728763.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。