Punycode の説明

プラトン再発行

フォロワー： 0

ASCII に制限されている場合、絵文字や非ラテン文字などのより複雑なものをどのように表現できるでしょうか? XNUMX つの答えは Punycode です。これは Unicode 文字を ASCII で表現する方法です。ただし、技術的にはUnicodeの生のビットを文字にエンコードできますが、次のように Base64、引っ掛かりがあります。ドメインネームシステム (DNS) では、通常、ホスト名は大文字と小文字を区別しない必要があるため、HACKADAY.com、HackADay.com、または単に hackaday.com と入力しても、すべて同じ場所に移動します。

【A. Costello] は、カリフォルニア大学バークレー校で Punycode のアイデアを提案しました。 RFC 3492 2003 年 XNUMX 月。これは、すべての通常の ASCII 文字を抜き出し、その間に区切り記号 (この場合はハイフン) を付けて片面に貼り付ける単純なアルゴリズムの概要を示しています。次に、Unicode 文字がエンコードされ、文字列の末尾に貼り付けられます。

最初に、数値のコードポイントと文字列内の位置が乗算されます。次に、数値は次のようにエンコードされます。ベース-36 (az および 0-9) 可変長整数。たとえば、挨拶と感謝のギリシャ語「ねえ、ευχαριστώ」 になるねえ、-mxahn5algcq2」. 同様に、美しい街 ミュンヘン になる mnchen-3ya。

ギリシャ語の例でお気づきかもしれませんが、base-36 文字がどの元の Unicode シンボルに属しているかをデコーダーが認識できるようにするものは何もありません。可変長整数のおかげで、エンコードできる数値にはしきい値があるため、各有効桁が認識可能です。有限状態マシンが助けになります。 RFC は、アルゴリズムの概要を示す擬似コードの例を示しています。デコードが進むにつれて変化するバイアスを利用するのは非常に巧妙です。常に増加しているため、いくつかの巧妙な特性を持つ単調関数です。

もちろん、通常の URL が Punycode として解釈されるのを防ぐために、URL には特別な小さな接頭辞があります。 ×n-- ブラウザにそれがコードであることを知らせます。これにはすべての Unicode 文字が含まれるため、絵文字も有効です。では、なぜあなたは行けないのですか？ xn--mnchen-3ya.de? ブラウザに入力するか、リンクをクリックすると、ブラウザが複雑な文字列を美しい URL に変換するのを目にするかもしれません (すべてのブラウザがこれを行うわけではありません)。最大の問題は Unicode そのものです。

Unicode は、毎日 Web で使用されている数百の言語を可能にするための素晴らしいサポートを提供しますが、あえて言えば、いくらか単純でさえありませんが、いくつかの欠点があります。キリル文字、ゼロ幅の文字、およびその他の Unicode の奇妙さにより、より悪意のあるユーザーがドメインを設定できるようになり、レンダリングすると、有名なウェブサイトとして表示されます. SSL 証明書は有効であり、他のすべてがチェックアウトされます。キリル文字には、視覚的にはラテン語の対応する文字と同じように見えますが、表現が異なる文字が含まれます。ハッカーやフィッシングの試みが行われる可能性が非常に高く、これまでのところほとんどのドメインで Punycode は許可されていません。

たとえば、これら XNUMX つのドメインの違いがわかりますか?

ハッカデイ.com

ハックデイ.com

一部のブラウザーは、ホバーテキストを Punycode としてレンダリングし、一部のブラウザーは、それを UTF-8 に相当するものとして保持します。「a」(U+0061) はキリル文字の「a」(U+0430) に置き換えられ、ほとんどのコンピューターはまったく同じ文字でレンダリングされます。

これは IDNホモグラフ攻撃、ユーザーがリンクをクリックすることに依存しており、それらのリンクの違いがわかりません。 2001 年に、XNUMX 人のセキュリティ研究者がこのテーマに関する論文を発表し、「microsoft.com」を概念実証としてキリル文字で登録しました。これに対応して、トップレベルドメインは、ラテン文字とその国で使用されている言語の文字を含む Unicode 文字のみを受け入れることが推奨されました。その結果、一般的な米国ベースのトップレベルドメインの多くは、Unicode ドメイン名をまったく受け入れません。少なくとも、表示できない文字は ICANN によって明確にバンド化されており、大量のワームを回避できますが、視覚的には同じでもビットごとに異なる文字が存在すると、混乱を招きます。

ただし、これらのタイプの攻撃に対する軽減策は徐々に展開されています。保護の最初のレイヤーとして、Firefox および Chromium ベースのブラウザーは、すべての文字が同じ言語からのものである場合にのみ、非 Punycode バージョンを表示します。一部のブラウザーは、すべての Unicode URL を Punycode に変換します。他の手法では、光学式文字認識 (OCR) を使用して、URL を別の方法で解釈できるかどうかを判断します。ブラウザーの外では、テキストメッセージまたは電子メールで送信されたリンクは同じようにスマートではない可能性があり、ブラウザーでそれらを開くまでわかりません。そして、それでは手遅れです。

課題はさておき、Punycodes は太陽の下で時間を過ごすことができますか? Hackaday は ☠️📅.com を取得しますか? 知るか。しかし当面は、2003 年に提案された、まだ完全には解決されていないドメイン名の国際化という厄介な問題に対する巧妙な解決策を利用することができます。