最近有白帽反馈了接入Sentry的安全漏洞，坏人可以进行SSRF攻击（Server-Side Request Forgery），其实还是挺普遍的，让我们来了解下。
漏洞详情：https://hackerone.com/reports/374737
前端小伙伴都很熟悉CRSF（Cross-site request forge ）跨站脚本攻击，主要是因为用户身份一般存在浏览器的cookie中，不同tab之间也能共享，只要坏人发出同域名的请求就可以携带cookie。
Forgery的意思是伪造，所以SSRF和CSRF有相通之处，都是坏人趁我们不注意让我们自己发了本来不想发及不该发的请求。
Sentry漏洞的成因
分析了下Sentry漏洞的成因：
1.因为错误上报信息的接口是对外暴露的，所以坏人可以伪造任意的错误上报信息
2.Sentry中Enable JavaScript source fetching（源码预获取）的选项是默认打开的，这个选项的作用是去抓取上报的错误JSON中的stack trace中的filename对应的url对应的代码，所以部署sentry的服务器会盲目的GET请求坏人的url，坏人就达到了通过我们自己的服务器发起恶意请求的攻击目的，可以从外网来攻击内网（SSRF）
3.同时我们最好配置下域名校验来过滤些无关的请求。
本来想说虽然配置了域名校验，坏人还是可以伪造refer和origin来直接发请求打挂我们的sentry，虽然打挂了也没啥可怕的，不影响线上服务。但是师父说了句很重要的观点
攻防对抗就是成本的对抗，攻击成本高，收益小的话也不会被认为是安全问题
简言之没人吃饱了没事儿发起这样的攻击。
修复方案也很简单，1.参照下图关闭源码抓取即可
2.最好限制下允许的域名
其他关闭源码抓取的原因
其实官方也推荐我们关闭源码抓取，原文在这里：关闭源码抓取的三个原因
简单总结下：
- 不一致性：
其实源码抓取的原理是通过爬虫抓取代码，所以经常会出现让人疑惑的地方，比如我的网站有海外版和国内版，明明是海外版报错，但是Sentry抓取的源码显示的对应行数可能是国内版的。而且用户可能很久没刷新页面，源码抓取展示的错误不是最新的，并不能对应到真正报错的行数。
- 不安全：
很多网站本来就不希望Sentry这样的爬虫来爬，可能会有反爬策略，这样Sentry的爬虫就完全无法work。
所以最佳实践是手动在Sentry中上传sourcemap，暴露在外的sourcemap也很可能会造成源码泄漏，上传在Sentry是最好的选择。
SSRF
再简单介绍下SSRF吧。以下内容来自 CTF Wiki
Server-Side Request Forgery，服务端请求伪造，是一种由攻击者构造形成由服务器端发起请求的一个漏洞。一般情况下，SSRF 攻击的目标是从外网无法访问的内部系统。
漏洞形成的原因大多是因为服务端提供了从其他服务器应用获取数据的功能且没有对目标地址作过滤和限制。
攻击者可以利用 SSRF 实现的攻击主要有 5 种：
- 可以对外网、服务器所在内网、本地进行端口扫描，获取一些服务的 banner 信息
- 攻击运行在内网或本地的应用程序（比如溢出）
- 对内网 WEB 应用进行指纹识别，通过访问默认文件实现
- 攻击内外网的 web 应用，主要是使用 GET 参数就可以实现的攻击（比如 Struts2，sqli 等）
- 利用
file协议读取本地文件等
SSRF 漏洞出现的场景
- 能够对外发起网络请求的地方，就可能存在 SSRF 漏洞
- 从远程服务器请求资源（Upload from URL，Import & Export RSS Feed）
- 数据库内置功能（Oracle、MongoDB、MSSQL、Postgres、CouchDB）
- Webmail 收取其他邮箱邮件（POP3、IMAP、SMTP）
- 文件处理、编码处理、属性信息处理（ffmpeg、ImageMagic、DOCX、PDF、XML）
这次的问题使我们了解了SSRF，通过外网来打内网服务，之前没关注到的领域，以后可以留个心眼儿。
