零宽字符对ENS的影响 或比你想象的更大

昨日，一位资深的 Web2.0 域名交易者「Hero 桀」在其个人 Mirror 上发表了一篇名为《请停止注册一切 ENS 域名，因为它一文不值》的文章。Hero 桀自称是资深 Web2.0 域名交易者，并曾卖出 xiaomiquan、wuyinli 等多个知名域名，目前仍持有 ouyi 这一优质域名。

该文章指出了一个肉眼不可见的「ZWJ（零宽字符）」所导致的设计疏漏，正为 ENS 埋下重大安全风险。该文章在部分加密社区流传甚广，并引发了部分投资者对 ENS 的质疑。

这一问题允许多个肉眼所见完全相同的.eth 域名同时出现。正如 Web3.0 革新了陈旧的传统互联网一样，在 Web3.0 时代，ENS 也为钓鱼攻击带来了 Web2.0 不曾出现过的全新升级的新方法。

在现阶段，「.eth」域名更多的被作为「网名」而广泛使用，一个独特的 eth 域名就像 Web2.0 时代的 QQ 靓号。在这种难以称之为基础设施的应用场景下，一些设计疏漏虽然会对用户造成困扰，但终归无法撼动 ENS 去中心化域名龙头的地位。

而在 ENS 的愿景实现之后，这个疏漏仍然是可以被忽视的吗？「Decentralised naming for wallets, websites, & more.」这是 ENS 官网上用醒目的字体所写的宏大使命。在这个愿景中，ENS 将成为命名一切数字资源的域名系统、打开 theblockbeats.eth 就像打开 theblockbeats.info 一样自然，而此时 ENS 的零宽字符将为整个 Web3.0 世界带来深远的安全隐患。

零宽字符，让 ENS 距离成为 Web3.0 基础设施更远了一步。

我，V 神，打钱

当你看到「vitalik.eth」时，你会认为这个人是谁？毫无疑问，这一 ENS 域名由 V 神所有。那么，我能否注册这一域名呢？按照 ENS 的规则，这一域名已被注册，其他用户自然无法在注册同样的域名。但值得注意的是，这里仅仅指对计算机而言完全一致的域名。那么，我有没有办法找到一个和 V 神域名有所不同但看上去又一致的域名呢？

当然可以，只要在任意位置插入 ZWJ 即可。

ZWJ（zero width joiner）即零宽字符，这一符号颇为特殊。对于计算机来说，ZWJ 仍然为一个字符，在 Unicode 字符集中拥有独立的编码，你在 Word 键入这一字符它仍会被计入字数统计。而这一字符的宽度却为 0，也就是说对于肉眼而言，零宽字符完全不可见。

这也就意味着，我只要在「vitalik」这一单词中任意位置插入零宽字符，即可注册一个肉眼看上去和 V 神域名完全一致的 ENS 域名。

在注册 ENS 域名时，只要在任意位置键入「%E2%80%8C」或者「%E2%80%8D」，即可在单词中插入一个零宽字符。这样，一个 V 神同款 ENS 即可成功注册了。如果插入零宽字符之后，依然已被人提前注册，你甚至可以插入连续的两个、三个、四个……多个零宽字符，直至尝试到无人注册为止。

做不好域名的 ENS，叙事难以持续

ENS 不止是 Ethereum 网络的重要基建之一，同样也是 Web3.0 网络的重要基建。ENS 的创始人曾公开表示，ENS 的愿景是要做「全球每一个数字资源的域名服务商」。不止是用户的账户名，更是整个 Web3.0 网络的命名系统。

还记得早年间关于 Web3.0 最初版本的想象吗？去中心化存储保存文件、去中心化域名提供寻址系统、智能合约拥有链上计算的能力、去中心化钱包充当支付通道，在这个版本的 Web3.0 中，一切都是运行于去中心化网络、无需许可、无审查的，这是一个真正自由的互联网。在这个版本中，使用 Web3.0 浏览器访问 theblockbeats.eth 就像你打开 theblockbeats.info 一样自然。

遗憾的是，这一版本的 Web3.0，至今尚未实现。且主流浏览器至今尚未支持.eth 域名的访问。尽管 ENS 仍在持续的建设之中，但它似乎难以成为这一版本的 Web3.0 的主流基础设施了。倘若真的建成，也将为 Web3.0 时代的网上冲浪留下巨大的安全隐患。

仔细回想一下，你是如何打开这篇文章的？

想必你定当是在某处见到了本篇文章的链接，鼠标或手指的一次点击，将你带到了这个页面。而绝非是在地址栏键入漫长的一串  https://www.theblockbeats.info/news/28611  。毋庸置疑，几乎所有的用户，都在使用 URL 进行网上冲浪。一个又一个纵横交错的超链接构成了我们当今时代的互联网，超链接组织起了互联网的繁杂信息、超链接为搜索引擎提供了寻找信息的技术基础、超链接为信息提供了开放自由的互联通道，可以说没有超链接，就没有当今世界的互联网。

基于 ENS 域名的 Web3.0 网站是否可以做到这一切？至少当前是极为困难的。因为它为我们带来了极大的安全风险。

在 Web2.0 时代，钓鱼网站攻击时刻都在对世界网民造成着严重的损失，而这还是在域名无法重名的情况下。想象一下，你在网上冲浪时看到网友分享的一个链接，该链接「肉眼可见」的是某知名平台，域名拼写和真实地址分毫不差，于是你便点了进去。但其实这是一个通过零宽字符伪造的钓鱼网站。

当用户只是进行点对点转账时，手动输入的习惯让零宽字符或许只是一个无关痛痒的恶作剧。而当 ENS 试图达到它的使命、命名一切数字资源时，这一切都变了。Web2.0 的钓鱼只是域名相似，而 Web3.0 的钓鱼已经迭代为完全一致。这将是一个重大的安全隐患。

我们处在一个基于超链接编织而成的互联网。DeFi、交易平台、Web3.0 博客、Web3.0 社交；网站链接、dapp 链接、API 接口链接、一切用例的入口链接……若以链接形式存在的.eth 域名不再可信，.eth 如何拓展它在「网名」之外的用例？如何成为 Web3.0 基础设施？ENS 域名的宏大叙事如何继续展开？这一风险或将从根基冲击 ENS 的估值体系。

而颇为讽刺的是，这一问题甚至在 Web2.0 中并不存在。

Web2.0 如何解决这一问题？

Web2.0 的解决方案简单明了——不支持使用零宽字符和拉丁字母的混排作为域名。具体可参阅《IDN2008 规范》的「UTS46」标准。

前文我们曾提到零宽字符「%E2%80%8C」和「%E2%80%8D」这两组神秘代码。这是 16 进制的 UTF-8 编码。它们的 Unicode 编号分别为「U+200C」和「U+200D」。这些字符通常被用于在阿拉伯文与印度语系等文字中，用于控制字符间是否产生连字的效果。在其他大多数语言中，你并不能打出这个字符。

而在 Web2.0 的域名注册中，此类较为特殊的字符并不被接受。但这并不代表 Web2.0 没有类似的攻击手段。事实上，外形相似的域名所伪装的钓鱼网站，一直在 Web2.0 的世界里广泛存在。

举个例子，你能否准确的区分"e" 和"е" 、"a"和"а"、「Ο」和「O」以及「О」？这些字母包括我们频繁使用的拉丁字母，以及较少用到的西里尔字母和希腊字母。

起初，域名注册仅支持 ASCII 字符，即我们口语中所说的「英文字母」和阿拉伯数字。这也是在世界各地被使用最为广泛的字符集，几乎所有支持字符显示的设备都支持 ASCII，但却不一定可以正常显示其他文字。在 IDN（国际化域名）普及之后，域名注册新增支持了多种语言文字，将支持字符从 ASCII 字符集扩展至部分 Unicode 字符集。这让世界各地的人民均可使用自己的母语注册域名，以中文为例，你可以通过「http://新华网. 中国/」直接访问新华网。

而在如此之多的文字中找到和拉丁字母相似的字符并不是什么难事。这种使用相似字符伪装成钓鱼网站进行欺诈的情况逐渐多了起来。这一欺诈被称为同形文字（homograph）攻击。

早在 2001 年，以色列的安全人员发表了一篇名为《同形文字攻击》的论文，并注册了一个包含西里尔字母的 microsoft. com 的变体。这也是可考证的第一个 homograph 欺诈域名。可以说，homograph 问题在 Web2.0 时代由来已久，但其危害性和严重性远不及 Web3.0 的 ENS 域名。

我们以一组 IDN 域名为例：ԚԚ.com、аӏірау.com、аӏірау.com。打开这些域名，你可以看到什么？

浏览器自动将域名转换为了以「xn--」开头的域名，这一编码方式被称为 Punycode。

在《IDNA2003》的规范中，为避免 homograph 欺诈，域名应经过二次处理，这一过程被称为「兼容性规范化 (compatibility normalization,NFKC)」。在非 ASCII 字符域名中，所有的字符都可被通过 Punycode 转换为更为通用的 ASCII 字符（「xn--」域名）。这一编码方式遵循 UTR36 标准，已被主流浏览器使用，这从用户端降低了 homograph 攻击的风险。

同样，在 IDN 域名的注册环节，ICANN 也做出了相应的规范。各国域名注册组织也在逐渐做出跟进，例如，俄罗斯的域名管理机构已经禁止了.ru 域名中混用西里尔字母和拉丁字母。

ENS 域名无疑支持着远多于 DNS 域名的字符，你不仅可以像 DNS 一样使用各种文字注册域名，甚至还可以使用 emoji 注册域名，以及本次被热议的安全隐患零宽字符注册域名。（值得一提的是，emoji 域名并不是 Web3.0 的特例，传统域名中的「.tk」、「.ws」等根域名同样也支持 emoji 注册。）

而在 Web3.0 中，我们能否通过相似的手段消除这一隐患呢？

面对 homograph attack，ENS 开发者态度暧昧

遗憾的是，ENS 开发者似乎并不打算从注册入口上解决这一问题。

在 ENS 社区的讨论中，这一问题早在 2021 年 4 月就已被用户提出。而 ENS 开发者对此的解释是，对零宽字符的支持是在合约层面的，因此无法移除对这些可能被用于欺诈的字符。此外，还有一个更重要的原因——零宽字符支撑着 emoji 在 ENS 中的应用。

ENS 创始人 nick.eth 针对零宽字符问题做出了这样的回应：「我们不像 ICANN 对大部分通用顶级域名那么严格，像 emoji 这样的域名就很好的运用了 ENS。」「ENS 禁止解析非 UTS-46 规范的域名并不在合约层面实现——将规范写入合约是不切实际的——这应作为客户端所需解决问题的一部分。」当然，他也对用户做出了积极的表态，「我们将考虑对规范化规则作出补充，以禁止您发现的这种情况。」

emoji 表情符号数量繁杂，事实上，有大量的 emoji 均为基础 emoji 的复合，例如，「女人」、「零宽字符」、「火箭」三个连在一起即会被计算机识别为「宇航员」。通过零宽字符，可以在精简编码集的基础上纳入更多的表情。而这也是 ENS 支持几乎所有 emoji 的基础。因此，ENS 无法屏蔽掉零宽字符的使用。

前文我们曾提到 Web2.0 的「.tk」域名，这是世界上第一个支持 emoji 的域名，传统的 Web2.0 域名是如何解决这一问题的？在前文提到的《IDN2008 规范》的「UTS46」标准中，零宽字符在不同文字中的使用、在 emoji 中的使用，均被做出严格规范。

在 4 月份的讨论中，nick 向社区成员解释，零宽字符的使用是在智能合约层级的，「不过，这很好，ENS 的设计一直是这样。」「白名单规则在这里没用，因为域名中可以包含多个字符，而不仅仅只是 emoji。」

风险控制与隐患消除

截至目前，我们尚未看到 ENS 团队在合约层面有任何修复这一安全隐患的举措。所有对于这一风险的防范均由中心化的 Web2.0 前端所作出。

在 OpenSea，包含零宽字符的 ENS 域名被标记上了黄色惊叹号。

在 etherscan，存在同样隐患的 ENS 域名则被标记了星号。

在 Metamask 上，虽然并不会额外给出风险提示，但 Metamask 可以识别到字符串中包含一位零宽字符，并用"?"将这一字符显示出来。

借助于中心化的手段，ENS 域名的安全风险在一定程度上有所减少。但当我们进入一个完全开放的 Web3.0 的世界，中心化的手段又将起到多大的作用呢？如果这隐患无法消除，ENS 距离他命名一切数字资源的愿景，仍然相距甚远。

在未来的某一天，有人发送给你一则网址为 www.binance.eth 的公告链接，你敢点开吗？