如何区分CSP报告是XSS攻击还是浏览器扩展？

我最近为一个相当复杂的Web应用添加了CSP（内容安全策略）报头，起初使用的是-report-only模式。在报告中，我收到了一些来自浏览器扩展的干扰信息，但有两个事件特别引起了我的注意：有一次报告了以下内容：

1
2
3


blocked_uri: blob
column_number: 155
effective_directive: script-src-elem

并且对于同一用户，在同一时间：

1
2
3


blocked_uri: https://overbridgenet.com/jsv8/offer
effective_directive: connect-src
source_file: blob

所以，显然是一个JavaScript blob:被注入了，并且它尝试连接到overbridgenet.com。这个域名的声誉可以说非常可疑。这个事件只发生了一次。另一个事件发生了两次：

1
2
3


blocked_uri: https://secured-pixel.com/inj/default.php?ext=12&tt=472-xx-12
column_number: 489
effective_directive: script-src-elem

两个不同国家的不同用户各发生了一次。URL查询参数略有不同（ext=12&tt=472-xx-12 与 ext=12&tt=024-xx-12）。其他部分包括列号都相同。关于secured-pixel.com我没查到太多信息。但它也有些可疑。那里无法访问任何内容，在谷歌上也查不到其背后的公司信息，只有关于域名本身的信息。如果我理解IBM的条目（https://exchange.xforce.ibmcloud.com/url/secured-pixel.com）正确，他们指出secured-pixel.com拥有/曾经拥有大量的DNS记录，即频繁更换DNS记录，并且其中一些DNS记录被IBM关联到恶意软件等。根据我的理解，可能发生了两种情况：

Web应用中可能存在XSS漏洞，并且一些攻击者利用了它。
一些用户的机器上可能感染了恶意软件或安装了恶意浏览器扩展，这些程序向某些（或所有）网站注入JavaScript。

如果这个假设成立：我如何才能查明这里属于哪种情况？我尝试过的方法：从报告本身，我发现用户访问的URL中没有URL参数（我尝试并检查过，如果有参数，报告中会包含）。因此，可以排除通过URL参数进行的反射型XSS。然后，我导出了相关用户可以访问的数据的数据库转储，并搜索了blob:和secured-pixel。为了覆盖简单的混淆技术，比如'b'+'l'+'o'+'b'+':'，我还搜索了"b"和'b'。然而，我什么也没找到。这里可能使用了更复杂的技术，但我找不到任何存储型XSS的痕迹。该应用是一个React应用。所以，XSS漏洞的数量应该非常少。我检查了所有使用以下内容的情况：

innerHTML
outerHTML
eval
new Function
setTimeout
setInterval

但我没有发现任何危险的东西。我不太清楚列号155和489具体指的是什么，但我检查了所有相关源文件在这些列（第1行）的位置，没有发现任何与XSS漏洞哪怕有丝毫相似的东西。我的GitHub仓库有Dependabot警告。但它没有警告任何与XSS相关的漏洞。我还能检查什么？

回答：

还存在第三种可能性：CSP违规也可能由完全良性的扩展或脚本触发。它并不总是XSS攻击或恶意软件。当你搜索secured-pixel.com时，你会发现很多网站明确在他们的cookie政策中提到了这个域名。当然，这并不能保证位于/inj/default.php的特定脚本就是无害的——也许该域名曾在某个时间点被恶意行为者接管，或者攻击者设法上传或篡改了该文件。但至少有一些迹象表明这可能是良性的，用于例如跟踪用户。对于overbridgenet.com的情况，搜索结果似乎指向一个浏览器扩展。如果是这种情况，你除了通知用户（如果可能）外，无能为力。不幸的是，调查CSP违规没有简单的方法。除非报告明确指出违规源头是你自己的脚本，否则这可能是一项漫长而复杂的调查。

如果可能，联系用户并询问他们是否安装了任何扩展或插件。这或许能让你重现该问题。
在你的整个应用代码中搜索这些关键词的出现。
考虑为特定用户记录响应体。这允许你搜索实际传输到客户端的JavaScript代码（包括存储型XSS）。无论如何，不要期望“完美”的CSP报告只包含真正的XSS尝试。人们会使用各种（有意或无意的）浏览器自定义功能来干扰网页，并可能触发CSP违规。