IDN ホモグラフチェッカー

異なる文字で綴られながら同じように読める 2 つの名前が存在します。apple.com と аpple.com — 最初の文字がキリル小文字の a — は、ネットワークにとっては別の名前で、読み手にとっては同じ単語です。このページは名前を分解し、そのどちらかを告げます:名前をラベルに分割し、すべての xn-- ラベルを運んでいる文字へデコードし、バイト数を DNS の上限と照合し、似た形の各文字をその借用元のスクリプトとともに名指し、名前全体を模倣する字形へ折り畳みます。 見つけたものと見つけられなかったものを、同じ詳細度で報告します。きれいな答えは「何も調べていない」ではなく「チェックが走って合格した」の意味です。
すべての処理はブラウザー内でローカルに行われます — 入力した名前がアップロードまたは解決されることはありません。

初めてですか?IDN ホモグラフを平易な言葉で解説 — punycode がすることとしないこと、ブラウザーがときどき xn-- を表示する理由、そしてこのページが判定ではなくチェックの集合である理由。
入力の読み方: 名前を先に NFC へ折り畳む
READS AS —
DNS FORM(リゾルバが受け取るもの) —
SIZE —
まだ何もチェックされていません。上に名前を入力または貼り付け — 一度に 1 つ — するか、例を読み込むを押してください。ページは裸の名前、URL から貼り付けた名前、URL 全体のどれでも読み取り、どれを取ったか告げます。実行するすべてのチェックは、何も見つけなかったものも含めて結果の下に一覧されます。
IDN ホモグラフとは?
ホモグラフは、ある書き方で綴られて別の読み方をする単語です。ドメイン名では、このトリックはたいてい 1 文字で済みます:apple.com はラテン文字 7 つですが、аpple.com は U+0430、キリル小文字の a で始まり、それは持っているどのフォントでも同じ形で描かれます。ネットワークにとっては 2 つの異なる名前。あなたの目には同じ単語で、Apple のものはそのうちの 1 つだけです。

DNS の最初の 20 年間、名前は ASCII のみでした。だからこそ名前に関するすべてがバイトと文字で測られます:文字・数字・ハイフンのラベルが各 63 バイトまで、全体で 255 バイトまで。国際化ドメイン名(IDN)は、その規則が Unicode の残りの部分に開かれたときに起こることで、punycode(RFC 3492)は古い機構を動かし続ける綴りの規則です:ASCII 外の何かを含むラベルは xn-- ラベル、つまり同じ文字を折り畳んだ形で運ぶ ASCII 文字列として書かれます。中文.com は xn--fiq228c.com として運ばれ、どちらの綴りも同じホストを名指します。

ここで重要なのは、punycode がしないことです。綴りを変換するだけで、それ以外は何もしません。аpple.com が apple.com の隣に座るのを許すべきかについて意見を持たず、尋ねることもできません。その問いはバイトではなく目とフォントについてだからです。どの文字を売るかはレジストリが決め、安全と考える名前をどう表示するかはブラウザーが決め、クリックするかどうかは読み手が決めます。このページは 3 つすべての下にある問いに答えます:この名前は実際にはどの文字でできていて、それで何と綴るのか?

このページが検証されるケース

下の各行は、ページが読み込み時に実行し、セルフテストボタンがもう一度実行するもので、ページは行が報告するとおりのもの — 同じ所見、同じレベル、同じ DNS 形式、同じバイト数、それ以上でも以下でもなく — を報告しなければなりません。ここできれいな答えに価値があるのはこのためです:普通の名前を通すコードパスが、下のトリックを捕まえるのと同じパスだからです。

ケースの内容 レベル 届いたときの名前 ページが報告すべきもの

このページの判断方法
  1. 貼り付けたものから名前を取り出す。裸の名前はそのまま使われます。URL はホスト名が取り出され、スキーム、ポート、パス、クエリは捨てられ、ページはどちらをしたか告げます。スラッシュを名前の一部のように黙って解析することはありません。
  2. クライアントと同じように清掃する。制御文字、幅ゼロの文字、バイト順マークは落とされ、全角または表意句点はドットとして数えられ、末尾のドットは間違いではなくルートです。このように取り除かれた、または再解釈された文字はすべて報告されます。黙って落とされた幅ゼロの空白こそ、告げてほしいものだからです。
  3. ラベルに分割し、それぞれを測る。ラベルは空であってはならず、ハイフンで始まったり終わったりしてはならず、xn-- ラベルでない限り 3・4 桁目にハイフンを 2 つ運んではなりません。各ラベルは 63 バイトの上限に対して UTF-8 バイトで測られ、名前全体は 255 に対して。
  4. すべての xn-- ラベルを文字へデコードする。デコードされたラベルはもう一度エンコードされ、入力と比較されます。そのラウンドトリップを生き延びないラベルは、名乗るラベルではありません。制御文字または空にデコードされるものは、黙って落とされるのではなく、そのように報告されます。
  5. 各文字が何であるかを尋ねる。コードポイント、UTF-8 バイト、属するスクリプト、似た形に描かれる文字のグループにいるか、そのグループの他のメンバーは何か。ここで、キリルの a は「1 文字」から「ラテン文字の形をした 1 文字」になります。
  6. 名前を模倣する字形へ折り畳む。似た形の各文字が模倣する文字に置き換えられ、аpple.com が apple.com になります。その折り畳まれた読みが、ページで最も有用な 1 行です。apple.com は行動に移せるものであり、「キリルの a」はそうではないからです。
  7. 所見を集め、最悪のものを報告する。所見は、現れるラベルとともに 1 件ずつ報告されます。一見変わっているだけの名前は、所見ではなくノートを生みます:漢字と仮名の混在やルートドットでの終わりは、心配の種ではなく普通の書き方です。

レベルと、それが主張するもの

none ここには言及する価値のあるものは何もなかった — low 同じ名前の別の綴り — medium DNS が運ばない文字、または普通の文字へ折り畳まれる文字 — high 別の名前として読まれるために作られた名前、またはまったく送れない名前。

レベルは、所見が最悪の場合に意味し得るものであって、確率でもサイトへの判断でもありません。完全に正直な名前が、ホスト名アルファベット外の 1 文字を含むだけでミディアムになり、敵対的な名前が、キリル文字 1 つという鮮やかでも何でもない手口でハイになることがあります。レベルの下のリストが理由を、所見 1 件につき 1 行で告げます。読むべきはそのリストです。

実行するチェックを 1 つずつ

下のテーブルはページが報告に使うのと同じリストから構築されるため、ここの行と結果の中の所見が矛盾することはありません。何も見つけなかったチェックは no として一覧されます。テーブルの要点は、問いが尋ねられ答えられたのが見えることで、「そもそも尋ねられたのか」を疑う必要がないことです。

チェック 最悪の意味 探すもの

同じリストがノートも駆動します。ノートはレベルをまったく持ちません:ドットを 1 つも含まないラベル、末尾のルートドット、ASCII でないトップレベルドメイン、ドット以外の区切り、大文字の名前、清掃中に取り除かれた文字、ホストに縮められた URL です。

DNS が強制する上限

名前はラベルのリストで、そのすべてが文字ではなくバイトで数えられます。この区別こそ punycode が存在する理由のすべてです:中文 は 2 文字で 6 バイト、その xn-- 形は 15 文字で、収まらなければならないのはエンコードされた綴りのほうです。ページは両方の上限を適用し、どちらに当たったか報告します。

上限 値 境界で起こること
ブラウザーがときどき xn-- を表示する理由

中国語やキリル文字で書かれた名前が、アドレスバーに期待した文字ではなく xn-- の意味不明な文字列として現れることがあります。それはサイトが登録に失敗したのではなく、ブラウザーが見やすい形の表示を拒んでいるのです。ブラウザーは見たことのない名前に独自の規則を適用し、その規則が存在する理由はこのページ全体が存在する理由と同じです:аpple.com を аpple.com として表示することこそ攻撃者が望むものなので、見慣れない混在スクリプトの名前は、十分に見られて信頼されるまでエンコードされた綴りで表示されるのです。

名前が現れる場所 表示されるもの 理由

このページが決してしないこと
これは判定でもブロックリストでもなく、チェックの集合です。名前が何でできているかを報告します。サイトが何をするかは分かりません。ここのすべてのチェックに合格した名前がフィッシングページであることも、混在スクリプトの名前と旗を立てられながら、自分の言語を書く人の完全に普通のウェブサイトであることもあり得ます。字形グループは UTS #39 の confusables の手書きの部分集合なので、このページが知らない文字のペアは報告されません。そしてここでは何も解決・ダウンロード・検索されません。入力した名前はブラウザーから出ない — つまりページは名前の存在も知り得ません。
規則の出所

Punycode は RFC 3492 で、このページのセルフテストはその文書に印字された 11 個のサンプルラベルを最初のチェックとして実行します。つまりここのエンコーダーは自分自身ではなく規格の中の例に対して保持されます。IDN が通る処理規則は RFC 5891(RFC 5892 の文字テーブル付き)、ブラウザーが実際に適用する互換層は非移行フラグ付きの UTS #46 です。このページはそれらを実装するふりをするのではなく、規則が何をするかを告げます。ここで実際に適用する折り畳み — NFC、次に小文字、次に RFC 3492 — は、名前が送信される前にクライアントが実行するのと同じ短いシーケンスです。このページファミリーの字形グループ、スクリプト範囲、不可視文字テーブルはファミリーのために手書きされました:規格は自分で読めるように名前が挙げられており、本文はここでは複製されていません。

質問

混在スクリプトの名前は常に攻撃なのですか?

いいえ。そう扱うのは重大な誤りです。日本語は同じ単語の中に漢字と仮名を書き、韓国語はハングルの中に漢字を書きます。普通の説明ができないのは、1 つのラベルの中にラテン文字とキリル文字やギリシャ文字が混ざることで、それらのスクリプトはどの言語でも一緒に使われないためです。ページはすべての混合に旗を立てるのではなく、その線を引きます。だからこそ上のケーステーブルの日本語と韓国語の行はクリーンに戻るのです。

では自分の名前がミディアムで返るのはなぜ?

たいていは、ホスト名アルファベットに含まれない文字 — アンダースコア、空白、互換文字として書かれたアクセント — を 1 つ含んでいるからです。名前はそのままでは送れないためミディアムです。ミディアムは「これを偽造だ」ではなく「見る必要がある」の意味です。レベルの下の所見が正確な文字と位置を名指します。

名前が危険か、登録済みか、到達可能か教えてくれますか?

3 つともノーです。ネットワークには一切触れず何も解決しないため、名前が存在するか誰が所有しているかは分かりませんし、サイトが何をするかについても意図的に何も言いません。自分で確認できる、より狭い問いに答えます:この名前はどの文字でできていて、似た形を本物の文字に折り畳むと何と綴るのか。

名前が中国語で、トップレベルドメインが ASCII でないと言われました。何か問題がありますか?

何も問題ありません。中国語のトップレベルドメインはそれ自身の xn-- ラベルとして運ばれるため、名前の最後のラベルはエンコードされた形で書かれ、ページはそれをノートします。ノートは事実を記述するものであって問題ではないため、レベルを持ちません。

reads-as の行が、入力したのと同じ名前を示すことがあるのはなぜ?

ページは、折り畳みが実際に何かを変えるときにだけ折り畳まれた読みを表示するためです。名前のすべての文字がすでに模倣する字形そのものであれば、折り畳まれた読みと名前は同じ文字列で、告げるべきことがありません。

A-ラベルと U-ラベルとは何ですか?

A-ラベルは運ばれる ASCII の綴りです:xn--fiq228c。U-ラベルは同じラベルを属するスクリプトで書いたものです:中文。1 つのラベルの 2 つの綴りであり、ページはデコードするすべてのラベルについて両方を表示します。エンコードされたラベルが何を隠しているか見えるように。