零宽字符对ENS的影响，或比你想象的更大( 三 ) 昨日

而在如此之多的文字中找到和拉丁字母相似的字符并不是什么难事。这种使用相似字符伪装成钓鱼网站进行欺诈的情况逐渐多了起来。这一欺诈被称为同形文字（homograph）攻击。
早在2001年，以色列的安全人员发表了一篇名为《同形文字攻击》的论文，并注册了一个包含西里尔字母的microsoft.com的变体。这也是可考证的第一个homograph欺诈域名。可以说， homograph问题在Web2.0时代由来已久，但其危害性和严重性远不及Web3.0的ENS域名。
我们以一组IDN域名为例：??.com、а??рау.com、а??рау.com 。打开这些域名，你可以看到什么？

文章图片
浏览器自动将域名转换为了以「xn--」开头的域名，这一编码方式被称为Punycode 。
在《IDNA2003》的规范中，为避免homograph欺诈，域名应经过二次处理，这一过程被称为「兼容性规范化(compatibilitynormalization,NFKC)」。在非ASCII字符域名中，所有的字符都可被通过Punycode转换为更为通用的ASCII字符（「xn--」域名）。这一编码方式遵循UTR36标准，已被主流浏览器使用，这从用户端降低了homograph攻击的风险。
同样，在IDN域名的注册环节， ICANN也做出了相应的规范。各国域名注册组织也在逐渐做出跟进，例如，俄罗斯的域名管理机构已经禁止了.ru域名中混用西里尔字母和拉丁字母。
ENS域名无疑支持着远多于DNS域名的字符，你不仅可以像DNS一样使用各种文字注册域名，甚至还可以使用emoji注册域名，以及本次被热议的安全隐患零宽字符注册域名。（值得一提的是， emoji域名并不是Web3.0的特例，传统域名中的「.tk」、「.ws」等根域名同样也支持emoji注册。）
而在Web3.0中，我们能否通过相似的手段消除这一隐患呢？
面对homographattack ， 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 。」