在这篇文章中，我将谈论几个月前发现的有趣的错误链。存储的XSS + IDOR（分别是跨站点脚本和不安全直接对象引用）。
目标是帮助管理财务的应用程序。在找到这个特定的错误链之前，我发现并报告了应用程序中的一些IDOR，这些IDOR已在30分钟内修复并付款。然后我想到一些IDOR在整个站点范围内，他们也对此进行了修复。
跨站脚本
它们具有在应用程序中要求供应商的功能。因此，我在“供应商名称”中注入了XSS有效负载，并要求供应商。起初什么都没发生，直到我选择删除供应商并弹出窗口！那是成功的，但是它似乎没有被利用，因为它已经被存储了，而是Self XSS。
PS：我没有在这里包括有效载荷，因为任何人都可以工作。
不安全的直接对象参考
尽管我知道他们过去已经修复了一些IDOR，但是无论如何都希望升级Stored Self XSS。对我来说幸运的是，我找到了另一个IDOR，该IDOR未被先前的修复程序处理。这次，我能够查看，编辑和删除其他用户的供应商。
PUT请求的主体如下所示：
{"shop_account_request":{"request_name":"Name of supplier","reference_contact_name":"ContactName","reference_contact_email":"Email","reference_contact_phone":"Phone","id":IncrementalID}}
然后，我可以通过增量ID将XSS有效负载设置为任何对供应商的请求的“供应商名称”。并且每当他们觉得名字很奇怪并选择删除时，就会执行XSS有效负载。
