在这篇文章中,我将谈论几个月前发现的有趣的错误链。存储的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有效负载。
网友评论