从Self-XSS到一个有趣的存储XSS

这是我写的第一篇漏洞悬赏文章，所以请对我宽容些！

所以我在Hackerone的一个程序中发现了这个XSS。而这个存储XSS的有趣之处在于，插入的payload生效的页面，这也是我在试着升级Self-XSS时幸运发现的。

我也不能透露这个程序名称，因为他们要求保密，但如果你找到它，我也不会感到惊讶。

现在让我们深入到这个漏洞站点，让我们称之为redacted.com

在对redacted.com研究了几个小时并试图在其上找到一个XSS时，我认为在这是不可能的，因为它正确地编码了所有敏感字符。即使我最终找到了一个，也是一个Self-XSS。

这不是一个大站点，在每个输入点都尝试了XSS之后，我放弃了，开始寻找其他类型的漏洞。

但是，第二天，我在Hackerone读了一篇关于AngularJS中模板注射的文章（https://hackerone.com/reports/250837），我感觉突然被启发了，貌似redacted.com也运行着AngularJS。

所以我尝试插入了一个简单的表达式，如{{4*4}}，如果后端对其不进行编码过滤，它将显示16，最后我找到一个不存在安全编码的页面。现在，我已拥有一个有用的xss payload {{constructor.constructor(‘alert(“XSS”)’)()}}。

哎呀！！！！我成功找到了XSS，但一分钟后我意识到……该死，是个Self-XSS！！！！

现在怎么办？？？？？

又经过数小时的测试，我发现了一个有趣的地方，它可以执行这个payload，并且不需要任何身份验证。

在此这个程序的背景，它有一个功能，就是可以通过电子邮件发送报告（无论这个网站做了什么），我们可以给这个报告自定义一个名字。这些报告是非常敏感的，只能被授权用户查看。而我发现这个报告的名字也存在Self-XSS，并且由于这些报告只能由授权用户查看，所以无法对其他用户发动XSS攻击。真的是这样吗？？？？

当我使用这个功能，通过电子邮件向我的邮箱发送了一份报告时，我在邮件角落里发现了一个小小的退订链接。

打开它，BOOM！！！！它展示的页面会出现这个报告名称，并且无任何身份验证。

接下来测试该页面是否会对{{}}进行编码

我快速地转到我的报告页面，将报告名称命名为{{constructor.constructor(‘alert(“XSS”)’)()}}，确定保存。再次打开取消订阅链接，BOOM！这就是一个存储XSS！

现在，当任何人打开这个该取消订阅链接时，这个XSS都会执行。不管受害者是否有授权，攻击都会生效。

经验教训：

1)查看程序上运用了哪些技术模板，方便找到特定的漏洞。

2)当你感到无聊的时候，尽量阅读些老的黑客报告。

3)尽量多的尝试——我阅读了大量的报告和记录，但是从未看到在电子邮件退订链接中存在XSS的报告。我本可以这只是一个Self-XSS，没想到最终成了一个新的存储XSS，我付出了更多的时间，并得到幸运女神的眷顾。

时间线：

09/10/2018-提交报告

10/10/2018-漏洞分级

11/10/2018-奖励发放

22/10/2018-问题关闭

谢谢阅读。

原文链接：https://nahoragg.github.io/bugbounty/2018/12/15/Self-XSS-to-Interesting-Stored-XSS.html