通过Report URI崩溃报告差点发现Chromium漏洞

追踪软件中的bug是所有编写代码的人都必须承受的痛苦。当我们在讨论网页中的明显错误时，通常会有一些线索可以入手（比如控制台输出），但这次的情况并非如此：

![Chromebook错误截图]

这是在Chromebook上出现的错误，也是我们在7月初首次收到的用户报告。这个问题最初带来的困难是，我们没有太多可以用于测试的设备。但有足够多的用户遇到了同样的问题，所以我们收到了多个类似的报告，这让我们不能简单地用"在我机器上正常"来回应像Peter这样的用户，然后就不了了之。

“SIGILL"错误意味着发生了相当底层的错误，从屏幕截图中可以看到，当网站甚至无法加载时，你无法简单地打开开发者工具查看网站中哪里出了问题。

然而，在数月毫无进展后，偶尔有Chromium用户报告完全相同的问题，答案终于浮出水面：

![CSP指令配置]

呃……浏览器不应该忽略它不认识的指令吗？（顺便说一句，report-sha256在CSP级别3中有文档记录。）但时间点与我们添加该指令的时间惊人地吻合，就在人们开始报告问题之前：

回到本文标题，我们差点就自己解决了这个问题，只是没有注意到眼前的数据。这就是Report URI的崩溃报告图表，直到6月份之前，我们的表现一直很好！

崩溃报告非常酷，因为客户的浏览器会自动生成它们，只需对响应头进行少量调整，你就可以轻松地将客户变成自动崩溃报告机器人！Report URI的价值主张（披露：我与他们有工作关系）是它可以接收这些报告并创建如上图所示的图表。我们只是没有足够密切地关注这些报告，因此标题中用了"差点”。

我想写这篇短文是因为有时候答案就在眼前，如果我们当时检查了事后看来非常明显的地方，我们几个月前就能解决这个问题。所以，开启崩溃报告功能，并密切关注它！

Report URI

本文强调了崩溃报告在识别和解决复杂软件问题中的重要性，特别是当传统调试方法无法提供足够信息时。通过实际案例展示了如何利用自动化报告系统来发现浏览器底层错误，为开发者提供了宝贵的技术洞察。