[ 欺騙和身份濫用 ]

同形異義域和國際化域模擬

透過保留經過驗證的身份形式、比較方法和實際接收者呈現來審查國際化域模仿。

由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 加密

知識庫