检测恶意 Unicode – 搞英语 → 看世界

在最近的一次教育技巧中，curl 贡献者 James Fuller 向该项目提交了一个拉取请求，其中他建议对一组脚本进行更大规模的清理。

在后来的演示中，他向我们展示了为什么团队中没有一个人审阅者或任何 CI 工作都没有发现或评论他所包含的一项更改：他在 URL 中用 Unicode 字母替换了 ASCII 字母。

这让我们几个人大开眼界，我们决定要更上一层楼。我们是 curl 项目，我们可以做得更好。

GitHub

替换符号看起来与 ASCII 版本相同，因此无法从视觉上发现这一点，但差异查看器知道存在差异。

在下面的 GitHub 网站截图中，我重现了类似的情况。右侧版本将拉丁字母“g”替换为亚美尼亚字母“co” 。它们看起来是一样的。

GitHub 显示了差异。但实际上差异是什么？

差异查看器显示存在差异，但人类根本无法察觉。这是缺陷吗？这重要吗？如果“正确”地处理，它应该与真正的、预期的修复一起完成。

当然，根据情况的不同，更改 URL 中的一个或多个字母可能会造成毁灭性的影响。

当我向 GitHub 的工作人员反映这个相当大的缺陷时，几乎没有收到任何回复，我感觉他们并没有理解和认识到这个缺陷的影响。又或许，他们只是忙着实现下一个我们根本不想要的 AI 功能而已。

本周早些时候，当我们在 Mastodon 上讨论这个问题时，Viktor Szakats 向我提供了一个使用 Gitea 执行类似操作的示例截图，这非常有助于强调替换的一些特殊之处：

Gitea 警告称，替换版本使用了“模糊的 Unicode 字符”

我听说其他一些源代码托管服务也显示类似的警告。

作为用户，我实际上想知道更多信息，但至少这足够清楚地警告了提议的更改，以便如果发生这种情况，我会手动获取代码并在接受此类更改之前进行调查。

在等待 GitHub 恢复并做出反应（我并不指望这在短期内真的会发生）的同时，我们已经实施了一些检查，以帮助我们这些可怜的人类发现此类问题。检测恶意的 Unicode。

我们添加了一个 CI 作业，用于扫描所有文件并验证 git 存储库中的每个 UTF-8 序列。

在 curl git 存储库中，大多数文件和大多数内容都是普通的 ASCII，因此我们可以“轻松”将一小组 UTF-8 序列和一些特定文件列入白名单，其余文件根本不允许使用 UTF-8，因为它们将导致 CI 作业失败并显示为红色。

为了彻底验证这一更改，我们检查了 curl 代码库中的所有测试文件，并确保所有 UTF-8 字符都被替换为其他类型的转义序列或类似字符。其中一些字符或多或少被误用，很容易被 ASCII 字符替换。

下次有人试图对我们耍这种花招时，可能是一个不怀好意的人，但现在理想情况下我们的 CI 会告诉我们。

有很多工具可以在不同的 Unicode 集中查找相似的字符。其中一个是由 Unicode 联盟自己提供的：

这又是一个针对已证实问题的安全相关修复。我相信还有很多问题我们尚未想到或尚未发现，因此我们没有足够的手段来自动检测和处理。

我们希望并努力在恶意攻击者利用某些弱点之前主动采取措施并加强一切，但安全仍然是一场永无止境的竞赛，我们只能尽力而为，而对方却在默默地工作，并可能在未来的某个时候以我们没有预料到的新的创造性方式攻击我们。

未来未知的攻击是一件棘手的事情。