前言：

最近和团队的小伙伴一起挖某src，也好久没有更新自己的博客了，所以拿出几个实战案例来分享。

作为一个向来喜欢寻找发现ssrf漏洞的漏洞赏金猎人，此文章就分享几个我在挖某src的ssrf实战案例吧。

案例:

export-pdf-ssrf:

这是关于pdf导出的ssrf技巧。我相信大家在很多场景下都遇见过关于导出功能的点。例如：

文章导出为pdf

项目导出为pdf

….

我在对一些资产进行访问观察时，发现了此处。这是一个将文章导出为pdf格式的功能点。这时我随便写下了一点内容，并点击导出后进行抓包。

burp收到请求后，我观察此数据包，发现了一个非常有趣的参数：html，对此分析以后，发现这是后端将前端获取到的内容转换成html格式再传入后端导出为pdf格式的文件。

ps：此包非常大，导致我的电脑接收的时候卡顿了10几秒，所以我并未截取原始数据包的截图。

这时，我思考到了html中的iframe标签，

IFRAME是HTML标签，作用是文档中的文档，或者浮动的框架(FRAME)。iframe元素会创建包含另外一个文档的内联框架

是的我想到可以使用iframe标签包含一个地址，后端在处理此标签时，是否会代出内容后整理成pdf文件返回给我。

事实可能并不为我所愿。他只返回了一个空的iframe框架给我。这时我依然并未放弃，因为我认为此功能点可能做过漏洞修复处理。

这时我想起团队群内某位队员发过的一篇文章：https://forum.butian.net/share/1497（我在熟读并背诵以后，我觉得可以尝试一下meta标签）,并且设置为0秒刷新请求。

1

<meta http-equiv="refresh" content="0;url=http://xxx.xxx.com" />

当我拿着返回的pdf文件下载地址的时候，我发现成功访问了jd的ssrf测试地址；

blind-ssrf（time determine）

图片检索功能，是一次非常常见的ssrf多发事故点。也是在寻找ssrf漏洞的必测点。在对某资产阅读以后，我发现了一处以图搜图功能。我向其赋值以后使用burp抓包

发现了一个非常有趣的参数：url。是的，这是一个非常常见的参数，我甚至在我的burp插件hae中也对这参数名称设置了一个红色

因为赋值一个地址以后，发现这不会返回任何有赋值赋值相关的内容。所以我赋值了我的一个dnslog测试地址。

从dnslog中，我得到了返回IP；对其查询以后知道这是来自上海某东云的云服务IP；随后我又测试了一个不允许访问的地址，例如google

在非常久的一个等待以后，我发现在返回时间这里出现了问题，他返回的时间足足有20秒之久。随机我立刻赋值了jd官方的ssrf测试地址；

他返回了一个正常的数据，并且是瞬间的完成了请求。

全文完。

原文始发于微信公众号（None安全团队）：SRC实战ssrf挖掘