首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Chromium 浏览器 IDN 同形字域名欺骗风险及防御研究

Chromium 浏览器 IDN 同形字域名欺骗风险及防御研究

原创
作者头像
芦笛
发布于 2026-10-12 07:15:05
发布于 2026-10-12 07:15:05
50
举报

摘要

国际化域名(IDN)同形字欺骗长期是网页钓鱼攻击的重要实现手段,Chromium 内核浏览器内置多重检测规则用于拦截视觉仿冒域名,但近期安全研究人员发现两个特殊 Unicode 字符可绕过现有防护逻辑,生成视觉高度近似正规域名的钓鱼域名,对 Chrome、Edge 等主流浏览器用户形成直接威胁。两类特殊字符分别为西里尔字母 “ө” 与带钩拉丁字母 “ƙ”,该组字符可以规避 Chromium 的混合脚本检测、Punycode 转码显示策略,地址栏直接展示伪装后的 Unicode 域名而非转码字符串,大量仿冒商业、政务、互联网服务站点的域名具备注册可行性,直接降低钓鱼攻击者实施域名欺骗的技术门槛。攻击者利用该缺陷构造仿冒域名搭建钓鱼站点,实施账号凭证窃取、恶意软件分发、金融欺诈等攻击行为,普通用户依靠肉眼几乎无法分辨真假域名。本文以 The Register 公开报道的安全事件为基础,梳理该类特殊字符绕过防护的技术机理,对比传统同形字欺骗与本次攻击手段的差异,分析浏览器安全校验逻辑存在的设计局限,评估该风险面向个人用户与企业机构的实际危害。迪妙网络空间安全学院研究团队针对该类 IDN 欺骗开展模拟复现研究,指出浏览器字符黑名单、脚本混合检测存在规则边界漏洞,单纯依赖客户端浏览器内置防护无法完全消除此类风险。反网络钓鱼技术专家芦笛指出,IDN 同形字攻击的演化表明钓鱼攻击正在不断利用编码层面细节绕过客户端防护,用户侧的识别能力存在天然上限,企业需要构建域名监测、网关过滤、用户安全教育的多层防御体系。本文从浏览器厂商改进、企业安全管控、终端用户意识提升三个层面给出可行防御路径,为应对新型 IDN 域名仿冒威胁提供实践参考。

关键词:Chromium;IDN 同形字;域名欺骗;钓鱼攻击;Unicode 字符;Punycode

1 引言

互联网域名系统引入国际化域名 IDN 技术之后,不同语言文字可以直接作为域名主体,不再局限于 ASCII 英文字母集合,极大提升非英语地区用户使用域名的便捷程度。IDN 域名底层依靠 Punycode 编码完成转换,将各类 Unicode 字符翻译为以 xn为前缀的 ASCII 字符串完成 DNS 解析。但是大量不同语言的 Unicode 字符存在字形高度相似的客观现象,由此衍生出 IDN 同形字欺骗攻击,攻击者选取视觉几乎一致、编码完全不同的字符替换正规域名内的字母,注册仿冒域名,浏览器如果直接渲染原始 Unicode 字符,普通用户很难区分真假网址,钓鱼站点借此获取用户信任,窃取账号密码、支付信息等敏感数据。

长久以来 Chromium 项目持续迭代防护机制,先后推出混合脚本检测策略、高危字符黑名单、Punycode 强制转码展示规则。当域名同时包含多种不同语系字符,或者包含已知高风险同形字符时,浏览器不再展示可读性强的 Unicode 域名,转而展示晦涩的 Punycode 编码字符串,以此提醒用户该域名存在仿冒风险,以此遏制同形字钓鱼攻击扩散。但是防护规则存在判定边界,部分边缘 Unicode 字符没有被纳入风险管控范围,就有可能绕过整套检测流程。

本次被公开的安全现象,正是两个少见字符突破现有检测规则,在 Chromium 内核浏览器地址栏直接显示伪装后的 Unicode 域名,不会自动切换展示 Punycode 编码。该现象不属于传统意义软件漏洞,更多是字符集判定规则遗漏带来的安全缺陷,不需要执行代码利用,攻击者仅需要完成域名注册即可开展攻击,攻击落地成本低、传播门槛小。迪妙网络空间安全学院研究团队梳理近年 IDN 安全事件后发现,浏览器的同形字防护始终处于攻防博弈状态,攻击者持续挖掘未被管控的稀有 Unicode 字符,以此规避浏览器内置安全策略,传统安全研究更多关注大规模已知同形字符集合,对于低频冷门字符带来的安全风险重视程度不足。

反网络钓鱼技术专家芦笛指出,很多企业安全建设将反钓鱼的希望寄托于浏览器自带安全能力,默认浏览器可以拦截绝大多数仿冒域名,忽略浏览器防护规则存在漏洞与更新滞后的现实情况,一旦出现新的绕过手段,企业员工、普通用户会直接暴露在钓鱼风险之下。本文围绕该起 IDN 域名欺骗事件,还原攻击实现条件,解析 Chromium 检测逻辑的短板,评估该风险对于不同对象的危害,并且构建完整的防护框架,客观讨论 IDN 机制下同形字欺骗的对抗难点,不做夸大式风险渲染,力求给出具备可落地性的分析结论。

2 IDN 同形字欺骗事件概况与危害表现

2.1 事件基本情况

安全研究人员针对 Have I Been Squatted 项目开展域名测绘研究,发现西里尔字母 “ө” 以及特殊拉丁扩展字符 “ƙ” 具备特殊的绕过效果,将这两个字符嵌入域名当中,构造和主流品牌域名视觉高度接近的 IDN 域名。当用户使用 Chromium 内核浏览器访问该类域名,浏览器现有的两套核心安全校验机制不会触发 Punycode 转码,地址栏向用户直接输出原始 Unicode 字符,肉眼观察和正规域名几乎没有差别。

研究团队已经实际注册二十余个演示域名进行有效性验证,部分仿冒域名视觉上和知名商业网站几乎一致。从底层编码属性来看,两个字符分属不同字符区块,西里尔字母 “ө” 属于西里尔扩展区块,而 “ƙ” 属于拉丁扩展字符集,二者字形分别与普通拉丁小写字母 o、k 高度近似。当攻击者把正规域名中的 o 替换为 “ө”,k 替换为 “ƙ”,其余字符继续使用标准 ASCII 拉丁字母,生成混合域名,该混合域名可以绕过 Chromium 的多脚本混合检测逻辑,不会强制展示 Punycode 编码。

需要明确的是,该现象并非浏览器出现远程代码执行漏洞,不存在内存破坏、代码劫持的问题,DNS 解析过程完全正常,域名本身可以通过正常域名注册商完成申请注册,攻击的核心危害来自于地址栏视觉展示欺骗。Firefox 等其他内核浏览器的字符判定集合和 Chromium 存在差异,该绕过现象不会在全部浏览器复现,风险主要覆盖 Chrome、Edge、Opera 以及其他基于 Chromium 二次开发的浏览器产品,用户基数规模庞大,影响范围广泛。

根据公开测绘统计,全球范围内存在超过 162000 组 IDN 域名具备类似构造特征,意味着可供攻击者使用的候选仿冒域名基数较大,攻击者可以针对金融机构、互联网平台、企业 OA 系统、政务服务站点批量生成候选钓鱼域名,域名注册成本低廉,黑产团伙可以批量持有大量该类域名储备用于钓鱼作战。

2.2 攻击落地的典型攻击链路

该类域名欺骗攻击的完整链路可以分为域名注册、站点搭建、流量诱导、信息窃取四个阶段。第一阶段攻击者选定目标正规域名,把域名内部的字母 o、k 替换为上述两个特殊 Unicode 字符,完成 IDN 域名注册;第二阶段在该域名之下部署钓鱼网页,页面 UI 完全复刻官方登录页面、业务办理页面,同时配置 SSL 证书,实现 HTTPS 加密访问,浏览器地址栏会展示安全锁标识,进一步迷惑用户;第三阶段攻击者通过邮件、社交软件、短信等渠道分发钓鱼链接,诱导用户点击访问仿冒域名;第四阶段用户在钓鱼页面输入账号密码、银行卡信息等敏感内容,数据被攻击者后台收集,完成凭证窃取,部分场景钓鱼页面还会诱导用户下载执行恶意程序。

整个攻击流程当中,HTTPS 加密锁标志和地址栏的伪装 Unicode 域名共同构建欺骗环境。普通用户习惯于依靠地址栏域名以及安全锁图标判断网站是否可信,当地址栏展示看上去完全正常的域名,同时具备加密标识,绝大多数使用者很难察觉字符编码层面存在差异。部分高级攻击场景当中,攻击者还可以搭配子域名、路径混淆手段,进一步提升识别难度。

2.3 面向不同主体的安全危害

2.3.1 普通互联网用户

普通网民缺乏 Unicode 编码相关专业知识,没有能力区分字形一致、编码不同的字符。遭遇该类钓鱼站点之后,极易泄露个人账户信息,涉及社交账号、网盘、电商账号、网络支付账户,会带来财产损失、个人隐私泄露等后果。普通用户依赖浏览器作为第一道安全屏障,浏览器防护出现绕过,直接剥夺用户的基础辨别条件。

2.3.2 企业机构内部用户

企业员工遭受此类钓鱼攻击会带来连锁风险。攻击者借助仿冒企业业务系统域名,骗取员工的办公账号、VPN 账号、域账号凭证,拿到企业内部访问权限,以此作为突破口,进一步开展内网渗透,后续可能引发数据泄露、勒索软件入侵事件。迪妙网络空间安全学院研究团队梳理多起企业安全事件,大量勒索攻击的初始入口来源于钓鱼获取员工账号凭证,新型 IDN 同形字欺骗进一步提升钓鱼攻击的成功率。企业对外的品牌声誉同样面临威胁,仿冒域名实施欺诈之后,受害用户容易将诈骗行为归罪于真实企业主体,带来品牌舆情风险。

2.3.3 政务与公共服务场景

政务平台、公共服务网站是钓鱼攻击的高频模仿对象。攻击者利用该类字符构造仿冒政务域名,诱导群众提交身份证、家庭信息等敏感个人资料,会造成大规模公民信息泄露,干扰公共服务秩序。政务场景下的钓鱼攻击具备极强社会危害性,域名仿冒带来的误导效果会放大社会层面的不良影响。

反网络钓鱼技术专家芦笛强调,和传统打字错误类域名抢注不同,该类 IDN 同形字攻击不需要修改字母顺序、增减字符,仅仅替换两个特定字符,整体域名视觉几乎无差别,即便是具备一定安全意识的人员,单纯依靠肉眼查看地址栏也容易出现判断失误,该特征是本次风险最值得警惕的地方。

3 Chromium IDN 防护机制与绕过技术机理

要理解本次安全事件,需要首先厘清 Chromium 原本用于对抗 IDN 同形字欺骗的两套核心防护逻辑,再分析两个特殊字符如何避开检测规则,同时区分本次攻击手段和过往同形字攻击之间的差异。

3.1 Chromium 原有 IDN 防护体系

Chromium 为处理国际化域名展示,设计两层主要校验逻辑,辅助以导航阶段安全提示,共同抵御同形字钓鱼。

第一,混合脚本检测机制。该规则核心逻辑是,如果一个域名标签同时包含来自两种或者更多完全不同书写系统的字符,判定为高风险域名,地址栏强制展示 Punycode 编码字符串,不再渲染 Unicode 原始字符。举例而言,同一个域名片段同时混杂西里尔字母和标准 ASCII 拉丁字母,就触发该规则,展示 xn开头的转码字符串,提醒用户该域名存在仿冒嫌疑。该规则的设计假设:正常合法业务极少会在同一个域名片段混合使用两套完全不同语言体系的字符,混合字符场景多数来自钓鱼攻击者构造仿冒域名。

第二,高危字符黑名单机制。浏览器维护一份风险字符清单,清单收录大量已经被证实常用于同形字欺骗的 Unicode 字符,域名当中一旦出现黑名单内字符,同样强制展示 Punycode 编码,规避视觉欺骗。黑名单来自过往安全事件沉淀,将已经被广泛滥用的同形字符纳入管控。

除此之外浏览器还会提供安全提示组件,当用户访问部分已知恶意域名时弹出安全警告页面。但安全提示依赖云端恶意域名数据库,数据库更新存在时间窗口,新注册的仿冒域名短时间不会被收录,因此该机制属于事后补充手段,无法从根源解决新构造 IDN 域名的视觉欺骗问题。

3.2 特殊字符实现绕过的底层原因

本次事件当中两个字符实现绕过,根源在于规则集合的边界遗漏。首先分析西里尔字符 “ө”,该字符虽然归属西里尔书写系统,但是 Chromium 的混合脚本判定逻辑中,该字符被归入特殊例外集合,当该字符和 ASCII 拉丁字母共同出现在同一个域名分段,并不会触发多脚本混合告警。而拉丁扩展字符 “ƙ” 本身归类属于拉丁字符集,从脚本分类层面不会触发跨脚本混合检测,同时该字符尚未加入高危字符黑名单。

二者组合使用或者单独使用,构造出来的域名不会命中上述两大强制 Punycode 展示条件。浏览器不会做转码处理,直接在地址栏渲染字形,而字形外观和普通小写 o、k 高度趋同,最终形成视觉欺骗效果。这里需要明确,不是浏览器解析代码出现 bug,而是脚本分类规则、黑名单列表没有覆盖这两个边缘字符,属于安全规则的不完备,而非传统程序漏洞。

迪妙网络空间安全学院研究团队开展模拟测试对比发现,很多其他西里尔字母,一旦和 ASCII 拉丁字母混用就会触发 Punycode 转码,但是 “ө” 属于少数例外项。该例外最初设立的初衷是为兼容部分合法西里尔国际化域名业务场景,却被攻击者利用,成为绕过防护的突破口。而拉丁扩展字符 “ƙ”,归类上属于拉丁脚本,混合脚本检测规则对其完全不生效,只要不在黑名单当中,无论和普通拉丁字母如何组合,都会直接展示 Unicode 原始字形。

3.3 与传统同形字欺骗攻击的对比

传统 IDN 同形字欺骗大多使用广为人知的西里尔字母替换 a、e、c 等字母,这类字符早已进入浏览器黑名单,只要域名出现就强制展示 Punycode 编码,攻击效果被极大削弱,攻击者使用这类字符构造的钓鱼域名,普通用户一眼就能识别晦涩的 xn前缀。

本次攻击选用的是低频冷门字符,避开黑名单与跨脚本检测,能够直接展示看起来 “正常” 的 Unicode 域名,攻击欺骗效果得到显著提升。传统打字错误域名抢注,一般是增加、删减、置换普通 ASCII 字母,域名会出现肉眼可见拼写错误;而本次 IDN 同形欺骗域名整体拼写观感与原版保持一致,仅仅编码底层字符发生替换,肉眼很难识别差异。

三者对比可以清晰看出风险递进:传统打字错拼域名存在明显拼写错误;经典同形字域名被浏览器强制显示 Punycode 编码;本次绕过手段生成的域名展示伪装后的正常 Unicode 字符,欺骗能力最强。

3.4 攻击落地的前置约束条件

该攻击同样存在客观约束,并非所有场景都可以生效。第一,域名注册机构需要支持包含这两个特殊 Unicode 字符的 IDN 域名注册,如果注册商拒绝该字符,攻击者无法完成域名申请;第二,域名后缀需要支持 IDN 域名解析,顶级域的配置会决定该类域名是否能够完成 DNS 解析;第三,浏览器版本的影响,未来 Chromium 项目更新字符规则之后,该绕过效果就会失效。

从现实网络环境看,已经有部分注册服务商支持该类字符注册,所以具备现实攻击条件。同时值得注意,即便浏览器后续修复该组字符,Unicode 字符集体量庞大,仍然有可能存在其他尚未被发现的边缘字符,未来继续出现同类绕过现象,IDN 同形字欺骗属于持续性攻防对抗问题,一次修复无法一劳永逸解决全部风险。

4 多维度风险根源剖析

该安全现象的产生,是 Unicode 字符集复杂性、浏览器兼容性与安全取舍、域名注册管控、用户认知短板多重因素叠加的结果,不能简单归罪单一环节。

4.1 Unicode 字符集本身的客观复杂性

Unicode 标准收纳全球几乎所有语言文字符号,不同语言之中大量字形互相近似。字符编码只区分字符语义归属,不会以视觉外观作为划分标准,不同编码可以对应高度相似的字形。字符总量庞大,浏览器厂商很难完整枚举全部具备仿冒潜力的字符,黑名单永远存在补充更新的过程,总会存在尚未被挖掘的边缘字符。部分字符设立例外分类,初衷是保障合法国际化域名业务可用性,安全和兼容性之间天然存在取舍,兼容场景的例外规则就有可能被攻击者滥用。

4.2 浏览器安全与业务兼容性之间的取舍矛盾

Chromium 开发团队在处理 IDN 域名时,始终要平衡安全风险和国际化业务可用性。如果采取最为保守策略,只要存在字形相似嫌疑就全部强制 Punycode 转码,固然可以压制同形钓鱼,但是大量真实合法的多语言 IDN 域名,都会展示晦涩编码字符串,普通地区用户完全无法阅读域名,国际化域名的业务价值就会丧失。

如果放宽规则,允许更多 Unicode 字符直接展示,又会引入仿冒欺骗风险。黑名单、跨脚本检测本质上属于折中方案,依靠规则列表做风险过滤,只要规则集合存在遗漏,就会产生绕过机会。迪妙网络空间安全学院研究团队在 IDN 安全专题研究中提出,这种兼容性安全矛盾是 IDN 机制与生俱来的困境,不存在完美的客户端判定策略,单纯依靠浏览器本地规则无法彻底根除同形字欺骗。

4.3 域名注册环节缺少针对该类风险的前置过滤

域名注册体系开放程度较高,绝大多数注册商面向全网开放 IDN 域名注册申请,注册环节不会专门针对字形仿冒风险做拦截。只要编码符合 IDN 技术规范,注册商便允许用户完成注册,注册商没有义务、也没有统一标准去判别申请的域名是否存在同形欺骗嫌疑。域名注册属于先注册后追责模式,只有当欺诈行为已经发生,权益受害方发起投诉之后,才会对恶意域名做处置,属于事后处置,无法提前阻止攻击者完成域名申请。

4.4 用户侧识别能力存在固有局限

反网络钓鱼技术专家芦笛指出,绝大多数普通互联网使用者不具备 Unicode 编码知识,分辨两个编码不同、字形几乎一样的字符已经超出普通用户的能力边界。安全教育反复提醒用户仔细核对地址栏域名,但当字符肉眼几乎看不出差别时,单纯依靠用户肉眼校验的防御思路已经接近失效。过去大量反钓鱼培训建立在 “用户可以肉眼识别域名拼写错误” 这个前提之上,本次攻击恰恰击穿该前提,说明终端用户识别只能作为辅助防线,不能当作主要防护手段。

5 事件处置与分层防御实现路径

针对该类新型 IDN 同形字欺骗威胁,需要构建厂商客户端更新、企业侧安全管控、域名权益保护、用户安全教育多层防御闭环,各个层级互相补充,不能把全部安全责任交由浏览器客户端承担。

5.1 浏览器厂商层面的改进方向

首先应当补齐现有字符判定规则,将本次发现的两个风险字符纳入管控,调整脚本例外规则或者加入高危黑名单,命中之后强制输出 Punycode 编码,消除该组字符的绕过能力。但修复单个字符只是应急处置,更需要完善整体检测框架。

第一,优化字形相似性辅助检测,不仅仅依靠字符脚本分类,增加字形相似度的参考维度,当域名内字符和 ASCII 拉丁字母视觉高度近似,即便属于同一脚本或者例外脚本,也要触发风险处理逻辑。但字形比对会带来性能开销以及合法域名误判问题,需要权衡误报率与检测效果。

第二,完善例外字符集合的审核机制,重新评估现有全部例外字符,梳理每一项例外设立的业务依据,评估被攻击者滥用的可能性,移除不再具备现实业务需求的例外项,收缩风险面。

第三,优化地址栏风险提示交互,对于高风险 IDN 域名,除切换 Punycode 编码之外,可增加醒目的视觉告警标记,即便用户看不懂 Punycode 字符串,也能够直观感知该域名具备风险。

第四,建立风险字符持续跟踪机制,和安全研究社区联动,及时接收安全研究者上报的新型绕过字符,缩短规则更新周期,提升对新出现绕过手段的响应速度。

5.2 企业机构的安全防护措施

企业是钓鱼攻击的重点目标,企业不能假设浏览器永远可以拦截全部 IDN 仿冒域名,需要在网关、域名监测、终端、管理机制层面补齐防护能力。

第一,开展仿冒域名持续监测。企业应当针对自身品牌、业务系统域名做 IDN 同形字域名监测,不仅监测普通 ASCII 错拼域名,还要覆盖各类 Unicode IDN 变体域名,及时发现攻击者注册的仿冒 IDN 域名。一旦监测到仿冒域名,及时走域名投诉处置流程,要求注册商暂停恶意域名解析,降低攻击对外暴露时间窗口。迪妙网络空间安全学院研究团队的企业域名防护实践表明,多数企业域名监控仅关注 ASCII 变体,忽略 IDN 国际化域名的仿冒监测,形成防护盲区。

第二,网络网关层面增加检测过滤。在企业上网代理、安全网关设备增加 IDN 域名解析检测能力,对访问的 IDN 域名做风险识别,识别具备同形欺骗特征的域名,给出告警或者直接阻断访问。网关检测独立于浏览器客户端,可以弥补浏览器规则尚未更新阶段的防护真空期,在浏览器补丁分发完成之前提供临时防护屏障。

第三,升级反钓鱼技术体系,不依赖浏览器云端安全列表作为唯一检测源,接入多源威胁情报,专门收录 IDN 同形钓鱼域名情报,用于邮件安全网关、网页网关。钓鱼邮件是该类攻击最主要传播载体,邮件网关在解析邮件内链接时,需要完整解析 Punycode 原始编码,展示底层真实域名,不要直接渲染 Unicode 展示给阅读者,防止邮件内链接直接利用字形欺骗收件人。

第四,账号安全层面强化身份防护。反网络钓鱼技术专家芦笛强调,即便无法完全阻止员工访问钓鱼页面,抗钓鱼多因素认证依然可以极大降低凭证泄露带来的危害。即便员工在钓鱼网站输入账号密码,如果启用抗钓鱼多因子认证,攻击者拿到账号密码之后依旧无法登录业务系统,把钓鱼攻击造成的损失控制住。企业核心 OA、VPN、业务平台应当全面部署抗钓鱼多因素认证,作为兜底防护手段。

第五,更新企业安全培训内容。网络钓鱼安全教育不能仅仅停留在 “看地址栏拼写”,需要向安全运维人员普及 IDN 同形字攻击的基础概念,告知运维人员存在肉眼无法分辨的域名欺骗手段,对于普通员工,则重点教育不要点击陌生来源链接,不随意在外部网页输入工作账号密码,调整安全教育的侧重点,不再过度夸大肉眼识别域名的作用。

5.3 域名注册与监管层面的可行建议

域名注册管理机构、注册服务商可以开展配套的风险缓解工作。针对高风险 IDN 字符组合,可以增加注册风险提醒,当申请者注册包含高风险字形近似 Unicode 字符的域名,向注册人做风险提示;建立仿冒域名快速投诉处置通道,当品牌权益方举证域名用于钓鱼欺诈,能够快速完成处置,缩短恶意域名存活周期。同时行业可以推动共享风险字符库,各个注册商、安全厂商之间共享已经被用于钓鱼的 IDN 字符集合,提升整个行业对同类攻击的感知能力。

5.4 普通用户的安全实践指引

对于普通终端用户,首先保持浏览器版本更新,及时获取 Chromium 项目发布的安全规则更新,修补该绕过风险。不依靠地址栏外观和 HTTPS 安全锁作为网站可信的唯一判断标准,重要业务尽量通过书签、系统自带应用进入服务,减少点击陌生短信、社交消息、邮件当中的外部链接。重要互联网账号开启多因素认证,降低密码泄露带来的账号被盗风险。遇到可疑网站,有条件的用户可以查询域名底层 Punycode 编码,查看域名真实编码字符串,确认是否包含异常 Unicode 字符。

6 结论与展望

本次由两个特殊 Unicode 字符引发的 Chromium 浏览器 IDN 同形字域名欺骗事件,并非一次破坏性巨大的软件漏洞,但具备很强的代表性,揭示国际化域名体系下攻防博弈持续演化的现实情况。攻击者不再依赖已经被广泛管控的经典同形字符,开始挖掘 Unicode 字符集内部的边缘例外字符,利用浏览器脚本分类规则、黑名单列表的遗漏,绕过客户端防护,构造视觉高度逼真的钓鱼域名,降低钓鱼攻击实现门槛。风险根源来自 Unicode 字符集本身复杂性、浏览器安全和业务兼容性之间的固有矛盾,客户端本地检测规则天然无法覆盖全部潜在风险字符。

迪妙网络空间安全学院研究团队认为,该事件只是 IDN 同形字对抗当中的其中一例,未来仍然会出现其他冷门 Unicode 字符被发掘利用,同类威胁会长期存在,不能期待一次浏览器更新彻底解决 IDN 域名欺骗问题。防御思路上需要跳出单纯依赖浏览器客户端防护的固有思维,构建浏览器厂商规则迭代、企业域名监测与网关过滤、身份安全兜底、行业域名治理、用户安全认知提升共同组成的多层防护体系。

反网络钓鱼技术专家芦笛强调,钓鱼攻击技术不断演进,攻击手段会持续利用编码、交互当中细微的设计细节来迷惑使用者,安全教育应当客观承认人眼识别存在能力上限,更多依靠技术手段兜底风险,而不是把防御的全部压力交给用户肉眼判断。对于企业机构而言,做好品牌域名风险监测、部署抗钓鱼多因素认证、在邮件和网络网关增加 IDN 域名检测,是应对该类威胁最高效的现实举措。

面向未来,IDN 域名安全领域还需要进一步研究兼顾可用性和安全性的检测算法,完善风险字符的发现机制,安全厂商、浏览器开发团队、域名注册行业应当加强协同,建立针对新型 IDN 同形欺骗的快速响应机制,以此应对持续演化的域名仿冒钓鱼威胁。

编辑:芦笛(公共互联网反网络钓鱼工作组)

来源:迪妙网络空间安全学院

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档