原文：
https://sm4rty.medium.com/stored-xss-via-invite-leading-to-mass-account-takeover-at-opera-a85ed257dd12
嘿伙计们! !我是Samrat Gupta，又名Sm4rty，一个安全研究员和漏洞赏金猎人。希望大家在当前新冠肺炎疫情中安全。我带着另一个博客回来了。希望你今天学到一些新东西。
这是一个关于存储XSS的故事，我最近在yoyogames.com上发现了它，这是Opera BugBounty程序的一个域名。让我们开始吧。
什么是存储的XSS?
存储XSS，也称为持久XSS，是这两种XSS中破坏性更大的，即基于反射的XSS和基于dom的XSS。当一个恶意脚本被直接注入到存储在服务器上的脆弱web应用程序中时，就会发生这种情况，因此更有影响。
我如何在Opera发现存储XSS?
一个月前，我就去opera打猎了。我选择的域名yoyogames.com是在BugCrowd的歌剧项目范围内。
首先，我开始初步侦察，即子域枚举，端口扫描，和运行nuclei（github上有）。然后我想以普通用户的身份来探索这些功能。
在应用程序中，我发现了一个用户可以创建发布者的函数。因此，我在发行者的Name参数上随机尝试了XSS有效负载。不出所料，什么也没发生，XSS没有触发。
</h4><script>alert(document.cookie)</script>
然后我进一步探索了这个应用程序，发现了一个功能，我可以邀请其他用户访问我刚刚创建的出版商。所以我在网站上创建了第二个账户。
对于第一个帐号，我只是邀请了第二个帐号到发行商。从Second Account，当我点击“接受”邀请。
BOOM! !XSS触发。
我再次尝试了相同的步骤，但我并没有接受邀请，而是点击了“拒绝”并看看XSS再次触发了什么。
所以，我太兴奋了，就向项目组报告了。但不幸的是，我迟到了一会儿。在我之前，已经有人报告了漏洞而我得到的只是一个副本。但我还是学到了很多。
关键:
当XSS有效负载不在一个地方触发时，并不意味着它就不脆弱。
尝试每个反映该参数的端点。
不要一试就放弃，试着挖得更深。
译者彩蛋：
有道翻译dom型xss
In the application, I found a function where user can create a publisher. So, I randomly tried an XSS payload </h4><script>alert('test')</script> at the Name parameter of the publisher. As Expected, Nothing happened and XSS didn’t trigger.
本文迁移自知识星球“火线Zone”
