[ 欺骗和身份滥用 ]

同形异义域和国际化域模拟

通过保留经过验证的身份形式、比较方法和实际接收者呈现来审查国际化域模仿。

由EmailAuth研究团队提供 · 8 分钟阅读

[ 要点 ]

  • 国际化命名合法;混乱并不能证明恶意。
  • 保持原始字符串、经过验证的DNS表单和骨架工件不同。
  • 接收器显示和结果需要观察到的证据,而不是假设。
在此页面上

将国际化与模仿分开

国际化域名让人们可以使用传统 ASCII 字母、数字和连字符之外的域标签。这种能力是合法且重要的。安全问题不在于特定脚本的存在;而在于是否存在特定脚本。这是一个显示的标识符是否可以与相应上下文中的另一个身份混淆的问题。因此,同形异义词或易混淆域调查必须保留实际名称、其经过验证的DNS表示形式和接收者的表示形式,而不声明每个非 ASCII 名称都是恶意的。

RFC 5890 定义了应用程序中国际化域名的术语,包括 A 标签和 U 标签。 Unicode 技术标准 39 描述了识别易混淆字符串的机制。这些是相关但不同的任务。 IDNA 的代表性和有效性并不是对隶属关系的判断;混淆性比较并不能证明欺诈。本文提出了一种无需注册名称、发送消息或访问可疑域的防御性审查方法。

保留表格而不是折叠它们

RFC 5890第2.3.2.1节将 A 标签定义为 IDNA 有效标签的 ASCII 兼容形式,将 U 标签定义为指定要求下的 Unicode 形式。并非每个以熟悉的 xn-- 前缀开头的字符串都是有效的 A 标签。解析器必须验证关系,而不是将前缀单独视为证据。同样,任意 Unicode 字符串不会仅仅因为它看起来像域标签而自动成为有效的 U 标签。

保留转换前的原始观测值。然后记录所使用的解析器和版本、它生成的经过验证的标签形式以及任何错误。将邮件客户端显示的值保留为单独的观察结果。屏幕截图可以记录外观,但不能替代底层代码点或解析的地址。该手稿没有运行标准化工具,并且不提供据称测量的转换。必须在授权的证据练习中生成并保留实际示例。

容易混淆的骨架不是DNS名称

Unicode TR39 描述了使用定义的转换和数据进行混淆检测。保留的当前文档包括方向感知骨架处理,并指出比较可能过于包容。骨架是一个比较工件。它不应用作要查询的地址、要列入白名单的域或要在DNS中发布的值。在比较方法下匹配的两个字符串不会成为相同的域或获得相同的所有者。

使用这种方法时,记录Unicode数据版本、算法和相关方向假设。不要将当前规范简化为未记录的指令以小写并替换视觉上相似的字符。那将是具有未知行为的不同算法。如果产品提供相似性分数,请将产品的方法和限制与标准分开保留。分数可以优先考虑人工审核,而无需确定恶意意图或接收者的实际显示行为。

呈现方式取决于消费应用程序

不同的应用程序和上下文可能会以不同的方式呈现相同的底层域。不要承诺每个邮件客户端都显示 Unicode、始终公开 ASCII 形式或始终对混合脚本发出警告。当前的接收者结果需要对相关客户端、版本、平台和消息上下文的实际观察。本文没有执行这些观察,因此没有声称特定提供商会显示或阻止特定的测试名称。

稍后收集授权证据时,请保留原始身份和用户所看到的内容。包括地址是否展开或折叠、显示名称是否单独显示以及哪个界面提供了任何警告。避免将一张屏幕截图推广到所有收件人。可访问性审查也很重要:视觉上的相似性和口头渲染可能会产生不同的理解问题,但如果没有适当的观察示例,则不应断言两者都是如此。

身份验证遵循领域,而不是感知相似性

RFC 9989,第 2.2 节指出 DMARC 不解决视觉上相似的域名或显示名称滥用问题。即使收件人将邮件误认为是受信任的组织,单独的域也可以对其自身进行身份验证。这不是停止检查的理由 结盟。这是保留实际域与接收者从其外观推断出的身份之间的区别的一个原因。

使用受信任的接收者身份验证证据,遵循信任边界问题 RFC 8601。记录哪个域经过身份验证以及评估哪个可见域。在评估它们之间的关系之前,不要用易混淆的框架替换这些域。标准化显示以进行比较不得默默地改变正在调查的协议身份。将身份验证结果和人类识别问题保持为相互关联但截然不同的观察结果。

身份表示工作表

使用原始消息字段、原始提取的域、需要的代码点表示、经过验证的 A 标签和 U 标签表单、解析器版本、验证结果和显示的客户端表单构建工作表。添加来自可信业务记录的比较目标、易混淆检测方法和版本、比较结果、接收者身份验证来源和请求的操作。包括观察到的事实和分析师解释的单独专栏。

为了保护隐私,请编辑不相关的消息内容和个人标识符,同时保留案例所需的确切域区别。不要仅仅为了说明工作表而将真正的可疑域发布为可点击链接。使用经批准的非交互式证据演示。如果虚构字符串用于教学,请将其标记为说明性的,并且不要声称它们已注册、被提供者接受或被接收者显示。捏造的接收者结果将违背证据要求的目的。

虚构的诊断:一个看起来很熟悉的名字

一位虚构的采购分析师注意到供应商消息似乎使用了熟悉的名称,但扩展的地址视图显示了不同的底层域。安全团队建议保留原始地址并使用记录的工具比较经过验证的表示。在这个阶段,团队担心的是混淆性,而不是恶意意图或所有权的证据。在正常业务流程下,所请求的供应商记录更改仍处于暂停状态。

该团队将通过已独立记录的供应商联系人来验证从属关系。如果授权调查继续进行,它还将保留实际的接收者证据。假设的情况故意不包括任何发明的 Unicode 转换、骨架输出或声称指定的邮件客户端显示特定字符​​串。这些是必须收集的观察结果,而不是为了叙述方便而填写的细节。在此工作期间,未查询、注册或使用任何域来发送邮件。

仅发布所需的示例

一个站得住脚的结论可以区分有效的表述、相似性、隶属关系、真实性和观察到的伤害。它可以说明比较方法发现了混淆而不声称有罪。它可以声明在不验证业务请求的情况下对不同的域进行了身份验证。它可以记录接收者的演示,而无需声明每个接收者的行为方式都相同。这些区别使得由此产生的指南在合法的国际化命名和假冒调查中非常有用。

该目录需要原始和显示的身份示例以及标准化的DNS形式和接收者结果。这些最初的观察结果仍然开放。这份手稿包含工作表和虚构的诊断过程,而不是证据。人类专家审查、来源适用性、生产路线、视觉可访问性和所有者发布也保持开放。发布需要保留、授权的示例,其中包含准确的工具版本和观察到的结果,并在不暴露不必要的个人数据或对域运营商提出未经证实的指控的情况下进行审查。

[ 外卖 ]

比较身份而不替换它们:有效性、相似性、从属关系和身份验证是单独的发现。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

证券分析师

保留每个表示

比较工件不能取代正在调查的身份。

后续步骤

  1. 保留原始值和工具版本。
  2. 将观察到的输出与解释分开。

消息传递专家

记录接收者行为

一张客户端屏幕截图并不能建立通用的呈现或过滤。

后续步骤

  1. 识别接收器和平台。
  2. 使用可信的身份验证证据。

辅助功能审核员

评估实际演示

视觉和口头身份呈现需要适当的观察。

后续步骤

  1. 在上下文中回顾保留的示例。
  2. 避免有关脚本或客户端的不受支持的假设。

[ 常见问题解答 ]

常见问题

所有非 ASCII 域都可疑吗?

不需要。国际化域名支持合法命名。必须在上下文中评估混淆性,而不是将脚本选择视为不当行为。

RFC 5890 :IDNA 定义和文档框架

什么是A标签?

它是RFC 5890定义下 IDNA 有效标签的 ASCII 兼容形式;单独的 xn-- 前缀不足以验证。

RFC 5890 :IDNA 定义和文档框架

什么是U标签?

它是满足RFC 5890指定要求的 Unicode 形式,而不是任意的 Unicode 字符串。

RFC 5890 :IDNA 定义和文档框架

骨架匹配是否建立了共同所有权?

不会。易混淆的检测会比较字符串,并且可能过于包容;它不确立所有权或意图。

Unicode 技术标准 39:Unicode 安全机制

骨架可以用作白名单中的域吗?

它不应取代实际经过验证的域身份。它是一个分析工件而不是DNS地址。

Unicode 技术标准 39:Unicode 安全机制

所有接收器都显示相同的形式吗?

这份手稿没有提出这样的主张。建立演示需要实际的客户、平台和环境观察。

视觉上令人困惑的域名可以进行身份​​验证吗?

单独的域可以对其自身进行身份验证; DMARC不处理视觉上相似的域名。

RFC 9989: DMARC

所需的原始示例和显示示例在哪里?

它们尚未被收集。该草案包含建议的工作表,而不是标准化的测试输出或观察到的接收器结果。

[ 来源 ]

来源

  1. RFC 9989: DMARC

    部分 §2.2 反网络钓鱼 · §2.4 超出范围 · §4.4 标识符对齐说明 · §11.4 显示名称攻击

  2. RFC 8601: Authentication-Results

    部分 §1.2 信任边界 · §7。安全考虑

  3. Unicode 技术标准 39:Unicode 安全机制

    部分 §4 易混淆检测 · §5.1 混合脚本检测

  4. RFC 5890 :IDNA 定义和文档框架

    部分 § 2.3.2.1 IDNA 有效字符串、A 标签和 U 标签 · §4 安全注意事项

[ 词汇表 ]

词汇表

A标签
RFC 5890中定义的 IDNA 有效标签的 ASCII 兼容形式。

RFC 5890 :IDNA 定义和文档框架

U-标签
RFC 5890定义的有效 Unicode 标签形式。

RFC 5890 :IDNA 定义和文档框架

骨骼
用于 Unicode 易混淆检测的比较工件,而不是DNS标识。

Unicode 技术标准 39:Unicode 安全机制

接收者介绍
在特定客户和环境中观察到的身份呈现。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库