うたカモ 技術知識・用語集

技術知識・用語集

セキュリティ

IDNホモグラフ攻撃

post:

IDNホモグラフ攻撃は、見た目がよく似た別の文字を使い、正規のサイトと同じに見えるドメイン名を用意する手法です。 IDN(国際化ドメイン名)でASCII以外の文字を使えることを悪用し、フィッシングサイトなどへ誘導するために使われます。

IDNホモグラフ攻撃とは?

ホモグラフ(homograph)は、もともと「つづりが同じで意味が異なる語」を指す言葉です。 この攻撃では、画面上では同じように見えるのに、文字コードとしては別の文字を使います。 例えば、ラテン文字のa(U+0061)とキリル文字のа(U+0430)は、多くのフォントでほとんど同じ形に表示されます。

見た目が似た2つの文字を虫眼鏡で比べるイメージ
見た目が似ていても、異なる文字が使われている場合があります。青とオレンジの点は、文字を区別するための目印です。

2002年には、Evgeniy GabrilovichとAlex Gontmakherが論文「The Homograph Attack」で、Unicodeを使ったドメイン名のなりすましを指摘しました。 その後、実際のドメインを使って同じ問題が示された事例もあります。

見た目が似ている文字の例

ラテン文字と見分けにくい文字は、キリル文字やギリシャ文字に多くあります。

ラテン文字似ている文字似ている文字の種類
a(U+0061)а(U+0430)キリル文字の小文字a
o(U+006F)о(U+043E)、ο(U+03BF)キリル文字の小文字o、ギリシャ文字のオミクロン
p(U+0070)р(U+0440)キリル文字の小文字 ER
e(U+0065)е(U+0435)キリル文字のイェ
c(U+0063)с(U+0441)キリル文字のエス
l(U+006C)ӏ(U+04CF)キリル文字のパロチカ

どの文字が似て見えるかは、使っているフォントによっても変わります。 Unicodeでは、こうした紛らわしい文字の対応をconfusables.txtというデータにまとめています。Unicode Technical Standard #39(UTS #39)は、このデータを使った判定方法などを定めています。

文字の置き換え方の2つのパターン

似たドメイン名を作る方法には、元の名前の一部の文字を置き換える方法と、すべての文字を置き換える方法があります。

一部の文字だけを置き換える

正規の名前のうち、一部の文字だけを似た文字に置き換える方法です。 次の例では、apple.exampleの先頭のaだけをキリル文字のаに置き換えています。

正規の名前
apple.example
画面での見え方
аpple.example
A-label(ASCIIの形)
xn--pple-43d.example

ドットで区切られた部分をラベルと呼びます。この例では1つのラベルにラテン文字とキリル文字が混ざるため、文字体系の組み合わせを調べると検出できます。

すべての文字を置き換える

ラベルのすべての文字を、ほかの文字体系の似た文字で書く方法です。 2017年には、セキュリティ研究者のXudong Zhengが、キリル文字だけで書いたаррӏе.com(A-labelはxn--80ak6aa92e.com)を登録し、当時のChromeやFirefoxでapple.comと同じように表示されることを示しました。

正規の名前
apple.com
画面での見え方
аррӏе.com
A-label(ASCIIの形)
xn--80ak6aa92e.com

このラベルはキリル文字だけでできているため、文字体系が混ざっていないかを調べるだけでは見つけられません。 UTS #39では、異なる文字体系だけで書かれた紛らわしい文字列の組を、whole-script confusablesと呼んでいます。 Chromeはこの問題を受けて、表示の規則を変更しました。

なぜ見分けにくいのか

DNSやブラウザにとって、apple.exampleとаpple.exampleはまったく別のドメインです。 Punycodeを使って変換したA-labelを比べると違いが分かりますが、画面にはUnicodeの表記が表示される場合もあります。

また、偽のドメインの持ち主は、そのドメインのTLS証明書を正規の手順で取得できます。 そのため、アドレスバーの鍵マークやHTTPSの表示だけでは、正規のサイトかどうかを判断できません。

ブラウザによる対策

主要なブラウザは、IDNをUnicodeの表記で表示してよいかをラベルごとに判断しています。次に挙げるChromeの規則は、2026年10月時点の資料に基づいています。 紛らわしいと判断したIDNのラベルは、xn--で始まるA-labelのまま表示します。

例えばChromeでは、次のようなラベルをA-labelで表示します。

  • ラテン文字・キリル文字・ギリシャ文字を互いに混ぜたラベル
  • キリル文字だけで書いたラベルのように、全体がほかの文字体系の名前に見えるラベル。ただし、その文字体系を使う国のトップレベルドメインなどでは例外がある
  • 似た文字や発音記号を取り除いて比べたとき、よく知られたドメインと一致する名前(例:googlé.com)

Chromeはこの表示の規則とは別に、よく知られたドメインに似た名前のサイトを開こうとしたときに、警告画面を表示する場合もあります。 Firefoxにも、ラベルに使われている文字などに基づいて表示を判断する仕組みがあります。

ただし、判断の規則はブラウザやバージョンによって異なります。 Unicodeの表記で表示されたからといって安全とは限らず、A-labelで表示されたからといって危険とも限りません。

ドメインの登録時の制限

ドメイン名を管理するレジストリの側でも、登録できる文字を制限しています。 ICANNのIDN実装ガイドラインには、登録できる文字やその組み合わせの規則を定め、公開するための指針があります。

例えば.jpの日本語ドメイン名で使える文字は、ひらがな・カタカナ・漢字、英数字、ハイフン、一部の記号に限られています。 そのため、.jpではキリル文字を混ぜた名前を日本語ドメイン名として登録できません。 一方、どの文字を認めるかはトップレベルドメインごとに異なるため、登録時の制限だけですべての紛らわしい名前を防げるわけではありません。

IDNホモグラフ攻撃を避けるために

IDNは、ASCII以外の文字を使う言語の利用者が自分の言語でドメイン名を読み書きするための仕組みです。 IDNやxn--で始まるドメインであること自体が、危険を意味するわけではありません。

ログインや決済を行うサイトは、メールやメッセージのリンクから開かず、保存したブックマークや公式アプリから開くと、偽のドメインに誘導されにくくなります。 パスワードマネージャーはサイトのアドレスに基づいて自動入力を提案します。いつもの画面で自動入力が出ない場合は、ドメインが違っていないか確かめるきっかけになります。

ドメイン名を調べるときは、Unicodeの表記だけでなくA-labelでも正規の名前と照合します。 つづりの誤りを狙うタイポスクワッティングや、正規の名前に単語を付け足すコンボスクワッティングも、似たドメインを使う手口です。

プログラムで紛らわしいドメインを検出するとき

サービスの側でユーザーが入力したドメインやリンクを確認するときは、UTS #39の仕組みが参考になります。 UTS #39のskeletonは、正規化や紛らわしい文字の変換によって作る比較用の文字列です。 2つの文字列のskeletonが一致すると、UTS #39の基準では紛らわしい文字列と判断できます。

例えば、キリル文字だけで書いたѕсореとラテン文字のscopeは、skeletonが一致します。 ICUのSpoofCheckerのように、この判定を実装したライブラリもあります。 比較する前に、IDNAの変換を行う関数でIDNをUnicodeのU-labelにそろえます。A-labelのまま比較すると、元の文字の見た目の類似性を調べられません。 一致は攻撃であることを意味せず、不一致でもすべての紛らわしい名前を除外できるわけではありません。

参考資料

技術知識・用語集に戻る