Unicode同形攻击新变种绕过Chromium检测，高仿真钓鱼域名可直接显示为正常字符

近期，安全研究领域披露了一类新型Unicode同形攻击（Homograph Attack）变种，其核心特征在于：攻击者可构造出在视觉上与知名品牌域名几乎完全一致的伪造域名，并在Chromium内核浏览器（如Chrome、Edge、 Brave等）中直接以可读的Unicode形式呈现，而非传统方式下显示为Punycode编码。这意味着用户在地址栏看到的不再是形如“xn--80a6aa68c8d.com”的乱码，而是清晰的“apple.com”字样——尽管底层实际指向的是恶意服务器。

该现象源于Unicode字符集的复杂性与浏览器对国际化域名（IDN）处理逻辑的细微差异。传统同形攻击依赖于使用外观相似但编码不同的拉丁字母变体（如将英文字母‘a’替换为西里尔字母‘а’），浏览器通常会将此类域名自动转为Punycode格式（以“xn--”开头）以警示用户。然而，此次发现的新手法利用了某些特定Unicode组合在Chromium渲染链中的异常行为：当域名中混入特定非拉丁字符（如某些阿拉伯语或希腊语变体符号）并配合特定TLD（顶级域）时，Chromium未能触发Punycode转换机制，反而将其完整渲染为看似合法的ASCII风格文本。

，研究人员实测发现，例如构造的域名“аpple.com”（首字母为西里尔小写а，U+0430）在部分Chromium版本中仍显示为“apple.com”，而其实际编码为“xn--80ak6aa92e.com”。更关键的是，这种渲染结果并非偶然错误，而是在特定字符组合与浏览器解析策略共同作用下的稳定表现。图中左右两组对比清晰展示了两种不同编码路径下，同一视觉呈现背后的底层差异：左侧为常规防护机制生效时的Punycode回退；右侧则为新型攻击成功绕过检测的情形。

这一问题的本质，是IDN处理标准（RFC 5891、RFC 5892）与浏览器实现之间存在的“灰色地带”。国际域名系统允许使用多种脚本字符注册域名，但为防止混淆，规范要求浏览器对“混合脚本”或“易混淆字符”应强制显示Punycode。然而，Chromium的IDN处理模块（基于ICU库）在判断“是否构成混淆风险”时，采用了一套启发式规则，包括字符所属Unicode区块、字体渲染兼容性、以及TLD白名单策略。攻击者正是通过精心选择字符组合（如避开高风险区块、选用低混淆度变体）和注册特定后缀（如“.com”本身未被列入严格校验列表），使整个域名被判定为“安全”，从而逃过Punycode转换。

值得注意的是，该漏洞并非Chromium独有，但因其市场占有率极高（全球桌面浏览器份额超65%），影响面尤为广泛。Firefox与Safari在默认配置下对类似构造仍会显示Punycode，表现出更强的防御倾向；但若用户手动关闭相关安全选项，亦可能暴露于风险之下。这反映出不同浏览器厂商在安全与用户体验之间的权衡差异：Chromium倾向于优先保障地址栏的可读性与简洁性，而其他引擎则更强调显式风险提示。

从攻击实施角度看，此类手法极大降低了钓鱼门槛。过去，用户只需留意地址栏是否出现“xn--”前缀即可识别仿冒网站；如今，即使具备基本安全意识的用户也可能被高仿真界面所误导。尤其在移动端，地址栏空间有限，Punycode原本就较难察觉; 而现在连这一最后防线也被突破。已有证据表明，部分恶意活动已开始尝试部署此类域名用于伪装银行、支付平台或云服务登录页，诱导用户输入凭证。

技术层面，该问题暴露出当前IDN安全模型的结构性局限。现有方案依赖静态字符黑名单与规则匹配，难以应对动态组合的混淆策略。随着Unicode持续扩展（目前已收录超过15万个字符），新字符不断加入，攻击面将持续扩大。更严峻的是，部分新型TLD（如“.app”、“.dev”）由Google等厂商直接运营，其注册政策虽禁止明显混淆域名，但对“边缘案例”缺乏有效审查机制。

安全社区对此提出多项缓解建议。短期来看，用户可启用浏览器的“显示Punycode”强制选项（Chrome中可通过chrome://flags/#show-idn-in-urls设置为Enabled），但这会牺牲部分正常国际化网站的可用性。中期方案包括推动ICU库更新规则库，增强对跨脚本混合字符的敏感度；长期则需重新审视IDN设计哲学——是否应默认隐藏所有非ASCII域名的原始形式，或引入视觉指纹比对等主动检测机制。

值得强调的是，此次发现并非首次揭示IDN风险，但其“绕过主流浏览器默认防护”的特性使其成为近年来最具实操威胁的同形攻击变种之一。它再次提醒：域名系统的信任根基建立在字符编码的精确性之上，而人类视觉系统的模糊性始终是安全链条中最脆弱的一环。在没有统一强制渲染策略前，用户对地址栏的“眼见为实”仍需保持审慎。

目前，Chromium项目组已确认该问题存在，并将其归类为“中等严重性”安全议题，正在评估是否调整IDN显示策略。尚未有公开补丁发布，但预计将在后续版本中加强字符组合的风险评分逻辑。对于企业安全团队而言，除终端防护外，还需在DNS日志与网络流量中部署针对非常规Punycode模式的异常检测规则，以提前拦截此类钓鱼请求。