0x01 SSRF漏洞简介
1.SSRF漏洞概述
SSRF(Server-Side Request Forgery:服务器端请求伪造) 是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。
一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。（因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内网。也就是说可以利用一个网络请求的服务，当作跳板进行攻击）
2.SSRF漏洞产生原因
SSRF 形成的原因往往是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。
如：从指定URL地址获取网页文本内容，加载指定地址的图片，下载等。利用的就是服务端的请求伪造。ssrf是利用存在缺陷的web应用作为代理攻击远程和本地的服务器。
3.容易出现SSRF的地方
- 转码服务
- 在线翻译
- 图片加载与下载(通过URL地址加载或下载图片)
- 图片、文章收藏功能
- 网站采集、网页抓取的地方。
- 头像的地方。(远程加载头像)
- 一切要你输入网址的地方和可以输入ip的地方。
4.如何测试 SSRF 漏洞
1.先验证对外请求能力，使用dnslog看看是否有http请求，总的来说，若只有DNS协议请求，存在 SSRF 的概率不大。
2.再换成src提供的靶子站或者内网ip地址127.0.0.1测试，如果这里是盲打ssrf就看看请求时间的变化。
再利用响应时间差异判断内网地址访问情况” 的思路，成功挖掘出盲 SSRF 漏洞。这种方法的核心是利用不同网络目标在被请求时响应时间的不同，来间接判断服务器是否能发起对特定内网地址的请求，从而在没有直接回显的情况下发现 SSRF 漏洞。
5.SSRF 案例实战
参考别人的案例
案例:export-pdf-ssrf:
这是关于pdf导出的ssrf技巧。我相信大家在很多场景下都遇见过关于导出功能的点。例如：
文章导出为pdf
项目导出为pdf
burp收到请求后，我观察此数据包，发现了一个非常有趣的参数：html，对此分析以后，发现这是后端将前端获取到的内容转换成html格式再传入后端导出为pdf格式的文件。
ps：此包非常大，导致我的电脑接收的时候卡顿了10几秒，所以我并未截取原始数据包的截图。
这时，我思考到了html中的iframe标签，
<iframe src="http://www.jd.com">IFRAME是HTML标签，作用是文档中的文档，或者浮动的框架(FRAME)。iframe元素会创建包含另外一个文档的内联框架
是的我想到可以使用iframe标签包含一个地址，后端在处理此标签时，是否会代出内容后整理成pdf文件返回给我。
事实可能并不为我所愿。他只返回了一个空的iframe框架给我。这时我依然并未放弃，因为我认为此功能点可能做过漏洞修复处理。
这时我想起团队群内某位队员发过的一篇文章：https://forum.butian.net/share/1497（我在熟读并背诵以后，我觉得可以尝试一下meta标签）,并且设置为0秒刷新请求。
<meta http-equiv="refresh" content="0;url=http://xxx.xxx.com" />
{
"html": "<li>1</li><meta http-equiv=\"refresh\" content=\"0;url=http://ssrf.jd.local/c3f3f53c12674acdc9855f47b85299f0.html \"/><iframe src=\"http://ssrf.jd.local/c3f3f53c12674acdc9855f47b85299f0.html \"",
"exportType":2
}
当我拿着返回的pdf文件下载地址的时候，我发现成功访问了jd的ssrf测试地址；
