Punycodeおよび類似の文字
Punycodeは、同一の文字に関する問題をどのように解決（または解決を計画）しますか？
現在、ほとんどのブラウザでは、言語設定で有効にしない限りPunycodeは無効になっています。
これは、キリル文字のような多くのアルファベットがラテン文字で使用されるaと同じように見えるaを持っていることを除けば、うまく機能します。後方互換性の理由でラテン文字を無視することはできません。そのため、キリル文字aを無視する必要があると思われます。
クライアントによって緩和方法は異なりますが、一般的なスレッドは、複数のアルファベットが使用されている場合、攻撃者がプニコードにフォールバックすることにより、異なるアルファベットの同音異義語を混合することを通常防ぐことです：
Google Chromeバージョン51以降では、Firefoxで使用されているものと同様のアルゴリズムを使用しています。以前のバージョンでは、すべての文字がユーザーの優先言語の1つ（および1つのみ）に属している場合にのみIDNが表示されます。
Safariのアプローチは、問題のある文字セットをPunycodeとしてレンダリングすることです。これは、Mac OS Xのシステムファイルの設定を変更することで変更できます。
Mozilla Firefoxバージョン22以降では、TLDがドメイン名で使用できる文字を制限することでホモグラフ攻撃を防止するか、異なる言語のスクリプトを混在させない場合、IDNが表示されます。それ以外の場合、IDNはPunycodeに表示されます。
キリル文字スクリプトのaa.comの具体的な例を説明するために、これを検出してpunycodeを表示するGoogle Chromeのルールを以下に示します。他のブラウザは一般的に同様のルールを使用します：
- ホスト名が 'com'、 'net'、 'uk'などの非IDN TLD（トップレベルドメイン）に属し、特定のラベル内のすべての文字がラテン語のように見える一連のキリル文字に属する場合文字（例、キリル小文字IE-е）、punycodeを表示します。
Punycodeは、同一の文字に関する問題をどのように解決（または解決を計画）しますか？
これを実行するように設計されていないため、解決しません（解決も計画もしません）（唯一の目的は、Unicode文字を使用するラベルを、ASCII小文字、数字、ハイフンのみを使用するラベルに変換することです。そして戻る）そして、あなたが暗示することはあなたが考えるよりもはるかに複雑です。
純粋にASCIIで同じ問題
まず、IDNで始まる問題ではなく、ASCIIでもまったく同じ問題があります。一部のフォントでは、1（数字1）、l（文字l）およびi/I（小文字または大文字の文字i）が非常に近く表示される場合があります、あいまいさの作成。
あいまいさは、コンピュータを理解するのがより難しい、これを取り巻くコンテキストのために、人間によってすぐに解決されることがほとんどです。
この問題を「解決」するアルゴリズムはありません。
IDN
IDNは、さまざまな規範と規制の交差点にあります。
- iETF標準があります：IDNA2003（IDNA自体は RFC3490 、Nameprep in RFC3491 、Punycode in RFC3492 およびStringprep in RFC3454 ）、次にIDNA2008（ RFC5890 の定義、 RFC5891 、 RFC5892 のコードポイント、 RFC5893 の右から左へのスクリプト、および RFC5894 ）の背景、実際には2010年に行われ、2つの間に大きな違いがあります。要約すると、IDNA2003は特定のバージョンのUnicode（したがって文字が利用可能）でブロックされました。どちらも、Punycodeを使用して国際化形式からLDH形式に移行しますが、IDNA2003には「StringPrep」予備ステップがあり、IDNA2008には特定の文字が再マップされる場所がありません（ドイツ語の1文字とギリシャ語の1文字の問題が発生するため、
.DE）のようにIDNA2008に切り替えたレジストリの例外であることに変わりはありません。 http://www.unicode.org/faq/idn.html のこのFAQは、それらの間の相違点、類似点、および問題を示しています - unicodeの推奨事項、特に UTS＃36「Unicodeセキュリティに関する考慮事項」 IDNAおよび「Punycodeなりすまし」および UTS＃46 "Unicode IDNA互換性処理」 は、主にIDNA2003からIDNA2008に移行することを扱います。また、 UTS＃39 "Unicode Security Mechanisms" を見ることができます。 "Confusable Detection"に関する完全なセクションと、 "紛らわしい"のリストを提供する関連ファイルもあります。 "（紛らわしいほど類似した）文字（ http://www.unicode.org/Public/security/latest/confusables.txt を参照）
- ICANNルール。ほとんどの場合、次のように要約できます。
- 単一文字TLDなし、2 ASCII文字はccTLDで、残りはgTLDです
- TLDは、2つの異なるプログラムの下でIDNになる可能性があります。IDNccTLDは、政府の要求に従って高速に追跡されます（そして、有名な「ホモグラフィック」攻撃またはそのような錯覚がそこに影響しました。たとえば、ブルガリアは、IDN TLD
bgはキリル文字でБГになり、ブラジルに近いbrに近すぎると見なされます。実際、ICANNはそのような「リスク軽減」のガイドラインを公開しましたケース： https://www.icann.org/en/system/files/files/guideline-risk-mitigation-measures-evaluation-28mar19-en.pdf ）、およびIDN gTLDは、2010年から2012年の新しいTLDのICANNの公開中に申請することが許可されたため、いくつかありますが、多くはありません（ https://www.iana.org/の下部を参照） domains/root/db ;一番下の理由？それらはLDH形式、つまりxn--somethingで順序付けられているため、明らかにxで始まり、アルファベット順ではありません） - tLDごとに許可される文字のリストは、関連する言語の言語専門家と連携して、ICANNが取り組んでいるリストのサブセットである必要があります。たとえば、 https://www.icann.org/resources/ pages/root-zone-lgr-2015-06-21-en ルートゾーン（許容されるTLDの場合）または言語ごとの https：//www.icann .org/resources/pages/second-level-lgr-2015-06-21-en
- レジストリは、「言語」またはスクリプトごとに許可される文字をリストするIDNテーブル（ https://www.iana.org/domains/idn-tables で入手可能）を公開する予定です。 、その他のルール、およびバリアントの処理
- 最後に、最も重要なルールの1つであり、問題に直接関係します。一部の言語では必要であるため、特定のケースを除き、ドメイン名の同じラベルに異なるUnicodeスクリプトからの文字を混在させることはできません
- 最後に、レジストリは上記のポイントのサブセットである場合とそうでない場合があるルールを所有しています。特に、過去に同じ課題を共有しているレジストリ（
.cn、.tw、.kr、.jpなど、一部のキャラクターを共有しているレジストリ）でも、全員が同時に開始したわけではないため、ルールと許可される文字のリストが異なる場合があります（さまざまなレベルで共通のセットに収束するための作業がありますが、これには時間がかかります）。
すべてのレジストリがgTLDであるわけではないため、ICANNの規則に拘束されるわけではなく、すべてのレジストリがIDNA2008に準拠しているわけではないことに注意してください。たとえば、このccTLDは管轄権があるため、ドメイン名を.wsの絵文字で登録できます。 http：// ???? .ws /を試してください！ただし、 https://www.icann.org/en/system/files/files/idn-emojis-domain-names-13feb19-en.pdf のこのICANNドキュメントを参照してくださいドメイン名の絵文字の問題に関する説明（グラフィック衝突の可能性がさらに多く、新しいFitzPatrick修飾子を考慮に入れていない場合もあります）。
ドメイン登録で実際に
すべてのレジストラがIDNを処理するわけではなく、すべて同じ方法で処理するわけではありません。通常、レジストリは、レジストラが登録するドメイン名に沿って「言語タグ」を送信することを期待しています。この言語タグでは、許可された文字の特定のリストを選択できます。それ以外の場合、言語タグがない場合、許可される文字のリストに加えて、唯一のルールは、異なるUnicodeスクリプトからの2文字を混合できないことです（特定の書記体系で使用される文字のセットであるスクリプト）。
言語タグは、実際に文字を混ぜる必要がある一部の言語に必要です。日本に行くと、電話番号や階数などの数字が、日本語のネイティブ文字ではなくラテン文字で書かれていることがわかります。これはとりわけ一例です。
上記のコメントで指摘された点をエコーするには、Verisign for .COMが、キリル文字を使用する言語（ロシア語、ウクライナ語、ブルガリア語、クルド語など）の言語タグの許可された文字の異なるテーブルを公開します（ https://www.verisign.com/en_US/channel-resources/domain-registry-products/idn/idn-policy/registration-rules/index.xhtml ）。それらをすべて見ると、キリル文字のUnicodeスクリプトのサブセットと、0から9までのASCII桁が表示されます。また、言語タグを提供しない場合、すべてのスクリプトが同じスクリプト内にある限り、Verisignで許可されている文字を使用する必要があります。
したがって、2つのオプション：
- キリル文字を使用する言語タグを提供することによって実際に
aа.comであるxn--a-8sb.comを登録しようとすると、キリル文字を使用するテーブルも同時にラテン文字（数字以外）を使用しないため失敗します - 言語タグを指定せずに登録しようとすると、複数のスクリプトの文字を混在させないという規則が適用され、登録は拒否されます。
そのため、特定のケースは実際に発生することはありませんが、もちろん、ドメインを別のドメインと「紛らわしいほど類似させる」他のケースもあります。
IDNホモグラフィック攻撃
これは、複数の文字が類似したグラフィック表現（ホモグラフィック）を持っているため、同じように見えるため、表示のあいまいさを重視している特定の問題です。
最初に観察：これは長い間知られています、そして、これを発見する誰でも長い間、作成されるすべての混乱のために世界の運命を予測するでしょう。実際には、私たちはそれをあまり見ないか、実際にはほとんど見ないので、ある特定のケースで時々新聞に掲載されますが、それ以外の時間では、IDNに基づくドメインサイバースクワットのケースは非常に少なく、 IDNに基づいた小さなフィッシングその中には、http://johndoe.tretre89.webhosting.somewhere.example.com/perso/misc/895f/bank.php?account=loginのようないものがあり、その周りに細工されたテキストと良いリンクがあり、一部の人々は銀行の公式ウェブサイトにそれらを置くという考えをクリックします！ドメイン監視サービスをブランドに提供するため、「紛らわしいほど類似した」ドメインを大きなブランドに登録するとアラートがトリガーされますが、上記のURLを使用すると、ウェブホスティングに侵入した後、peoplの前にアラートがトリガーされませんeフィッシングとして報告します）。
したがって、問題/攻撃は紙の上に存在しますが、実際には、好奇心とエッジケースとして今のところ残っています。
上記のルール、具体的にはスクリプトの非混合は、そのような問題を制限するために具体的に配置されました。 Maximillian Laumeisterの答えで説明されているように、ブラウザ（ただし、ここでは実際にURLに表示されるドメイン名を扱っていますが、メールアドレスやXMPP識別子など他の多くのものに表示されることに注意してください... Webブラウザーに制限されている）は、通常、スクリプトの混合を検出した場合、または一部のTLDで「危険」と判断した場合にPunycodeフォームに戻るルールを実装します。
それらはいくつかの問題を軽減しますが、すべてではありません。
раураӏ.comを取りましょう。これは有効なドメイン名であり、（特定のラベルの）すべての文字が1つのスクリプトに含まれているため、登録できます。しかし実際には、最初のバージョンはキリル文字のみを使用し、LDHでPaypal.comに変換するため、ASCIIバージョンxn--80aa0cbo65f.comとは関係ありません。冒頭で説明したように、この問題はIDNでは発生しません。純粋なASCIIのままであれば、まったく同じ問題が発生します。
そのようなケースを禁止することは、多くのEdgeケースと誤検知で非常に難しい問題になります。あなたは想像することができます：各文字を1つずつ取り、類似のいくつかの定義のためにグラフィカルに表示されるUnicodeの他のすべての文字を見つけましょう。そして、文字列を比較してраураӏ（100 ％キリル文字）およびPaypal（100％ラテン語）は「同じ」です。一方が存在する場合、もう一方は禁止されます。そのためのアルゴリズムとそのすべての警告については、UTS＃39を参照してください。
フォントに依存するグラフィック表示の問題に加えて、アジアやアラビア語の文字を考慮すると、事態はさらに複雑になります（ここで、すべての言語が左から右に書かれているわけではないことを考慮しなくても、アラビア語は1）、バリアントの問題を正確に示します。
バリエーションのバリエーション
中国語は有名で「単純な」例です。実際には、「繁体字」中国語と「簡体字」中国語があります。コンテキストまたは場所に応じて、両方がまだ存在するため、ドメイン名は両方を処理する必要があります。しかし、2人の別々の登録者が一方を名前の伝統的な中国語版ともう一方を簡略化したものとして登録できるようにすることは理にかなっていますか？おそらくない。非常に多くのレジストリがバリアントとブロッキングルールを定義しています：文字Xが文字Yのバリアントであると定義すると、Xが名前に含まれる場合、XがYに置換される他の名前は登録が禁止されるか、同じ登録者。
時にはルールも短命です。たとえば、.FRは何百万もの.FRドメイン名が存在するという事実のはるか後にIDNを導入したため、一定の期間、「祖父」アプローチを実装しました。たとえばcafe.frを持っている場合は、café.frの唯一の適格な登録者でした。これは、これがIDNの「バージョン」に近いためです。その期間が経過すると、キャラクターでプレイしているドメイン名または既存のドメイン名のバリエーションは、誰でも登録できるようになりました。しかし、これを読むだけでも、実際にはこのケースまたは同様のケースで見られるように、実際の問題はありませんでした（これは既存の純粋なASCIIベースのドメイン名）。
IDNについてのVerisign FAQからの次のスニペットは、主題に触れ、悲しい真実を伝えます。
技術コミュニティのさまざまな思想的指導者は、キャラクターバリアントの問題に対処するためのさまざまなアプローチを提案しています。各アプローチには、プラス面とマイナス面の両方があります。ただし、IDNコミュニティは、言語は常に変化の状態にあるため、キャラクターバリアントの問題を完全に解決できない可能性があることに同意しています。言語間の新しい文字バリアントは、引き続き言語に導入されます。
IDNテーブルを見ると、レジストリは言語タグごとに許可された文字をリストするだけでなく、各文字のバリアント（ある場合）もリストしていることがわかります。リストが巨大になると、これにより巨大な計算上の問題が生じます。
また、一部の言語では特定の場所や他の文字の前後に一部の文字が表示されないため、可能な限りすべてをエンコードしません。それを処理するため、そしてIDNテーブルの将来として、IETFはラベル生成ルール（LGR）と呼ばれる新しい標準を作成しました。これにより、XMLベースの構造でIDNとバリアントに関するすべてのルールをエンコードできます。ユニコード、正規表現、およびドメイン名についての十分な理解がなければ、その仕様を理解することを望まないでください。