ChromiumのIDNスプーフィング対策、見分けのつかない類似ドメインを見逃す
ChromiumのIDNスプーフィング対策は、欺瞞的なUnicodeアドレスを露出させるために長年講じられてきた保護策にもかかわらず、登録済みの類似ドメイン20件を見逃していた。概念実証用ドメインの1つはapple.comに酷似しているが、xn--で始まる目立つPunycode形式ではなく、読みやすいUnicodeとして表示される。
この発見は、攻撃者がAppleのドメインを登録した、あるいは同社のインフラを侵害したことを意味するものではない。Have I Been Squatted（HIBS）の研究者は、「apple」のラテン文字に似たキリル文字を使う別のドメインを登録した。テスト結果は、慎重に選ばれた文字がChromiumの表示ルールと、ナビゲーション時に働く別個の防御機構をすり抜けうることを示している。
この結果は、国際化ドメイン名が広く使われ始めて以来、ブラウザが管理してきた対立を改めて浮き彫りにする。ウェブには、人々が実際に使う言語で記述されたアドレスが必要だ。しかし同じ文字の多様性は、攻撃者に信頼されるブランド、IDプロバイダー、決済サービスを模倣する手段を増やす。
Chromiumはすでに、業界でも特に詳細な防御システムの1つを適用している。文字体系、不審な文字の組み合わせ、既知のドメイン、閲覧履歴を確認する。新たな事例はこれらの保護を無意味にするものではない。それぞれがわずかに異なる判断を下す複数の層の間に、少数の文字が入り込めることを示している。
研究者がChromium IDNスプーフィングの新たなエッジケースを発見
重要なのは忘れられていた攻撃手法の復活ではなく、現在のChromiumチェックが依然として説得力のある新しい変種を許している証拠だ。
HIBSの研究者であるIan Muscat氏とLeanne Briffa氏は、2026年10月3日に分析結果を公開した。国際化ドメインが、ChromiumベースのブラウザでUnicodeとして表示されたまま、有名なラテン文字ドメインに似せられるかを検証した。
国際化ドメイン名（IDN）には、基本的な英字アルファベット以外の文字が含まれる。アプリケーションはDNSリクエストを行う前に、これらの文字をPunycodeと呼ばれるASCII互換表現に変換する。したがって、xn--で始まるドメインが自動的に危険というわけではない。これは既存のドメインネームシステムで必要となるエンコード形式だ。
ブラウザは、表示時にこのエンコード形式を読みやすいUnicodeへ戻すことが多い。これにより、アラビア語、キリル文字、中国語、その他多くの文字体系による正規のアドレスをサポートできる。セキュリティ上の問題は、異なる文字がほぼ同一の形状を持つ場合に生じる。
研究者らが注目したのは、一般的なフォントではapple.comに見える可能性があるドメインаррӏө.comだ。その文字はすべてキリル文字で、ラテン文字の「a」、2つの「p」、そして「l」に似た文字が含まれる。最後のキリル文字өは、アドレスバー程度のサイズで表示されると、丸みを帯びた「e」に似て見える。
このアドレスはapple.comではない。エンコード形式はxn--80a6aa68c8d.comであり、DNSはこれを別個の名前として扱う。それでも読みやすい表示版は、訪問者がAppleのドメインに到達したかのような視覚的印象を与えうる。
HIBSは概念実証として、このドメインと追加の類似ドメイン19件を登録した。リストには、OpenAI、Skype、SharePoint、SpaceX、Shell、Xerox、Kaspersky、Okta、Nikeなど、広く知られた組織に関連する名称を模倣したものが含まれていた。
元のIDN研究によると、Chrome 154は有効な証明書とともにAppleの類似ドメインをUnicodeで表示した。また、研究者が評価したナビゲーションチェックも、類似ドメイン警告を出さずに通過した。
有効な証明書は、ドメインが似せているブランドに属することを証明するものではない。ブラウザが、その証明書に記載されたドメインとの暗号化接続を確立したことを確認するだけだ。攻撃者は、欺瞞的なドメインを含め、自らが正当に管理するドメインの証明書を取得できる。
これらの例は管理下での登録であり、挙げられたすべての企業の顧客を狙うキャンペーンの証拠ではない。技術的に実現可能ななりすましが、自動的に活動中のフィッシング作戦を意味するわけではないため、この区別は重要だ。
それでも、技術的な実現可能性そのものが今回の発見である。欺瞞的なドメインは、実際のウェブサイト、HTTPS、メール、リダイレクト、その他の通常のインターネットサービスを支えられる。攻撃者はその後、視覚的な類似性を検索広告、不正メール、QRコード、短縮リンク、コピーされたログインページと組み合わせることができる。
この研究は10月18日、タイポスクワッティング調査でより広く取り上げられ、キリル文字への置換がChromiumのルールをどのように生き残ったかが詳述された。このタイミングにより、ブラウザが不審なものを検知しない限り多くのユーザーが目にすることのない防御策に、再び注目が集まっている。
ここに本記事の中心的な緊張関係がある。Chromiumは、欺瞞的な視覚置換と、何百万人もの人々が使う正当な単語を区別しなければならない。あらゆる類似性を捉えられるほど広範なルールは、通常の国際化アドレスを読みにくく、信頼しにくいものにもしてしまう。
Chromium Unicode類似文字が複数のチェックを通過する仕組み
Appleの類似ドメインが通過できるのは、ユーザーに届く完全な視覚的印象を評価するChromiumルールが1つもないためだ。
Chromiumは、ドメインにUnicodeが含まれるかどうかを単純に確認するわけではない。IDNを複数のテストに通し、読みやすい文字を表示するか、基礎となるPunycodeラベルを表示するかを決める。
最初の主要な層では、International Components for Unicodeのスプーフチェッカーを使用する。Chromiumはこれを「Highly Restrictive」レベルで設定し、疑わしい文字体系の組み合わせを制限している。
ラテン文字の中にキリル文字が1つ混在するラベルは、通常このテストに失敗する。たとえばapple.comの最初の「a」だけを置き換えると、Chromiumはxn--pple-43d.comを表示する。このエンコードされたアドレスは、元のアドレスと誤認される可能性がはるかに低い。
新しいAppleの類似ドメインがこの結果を回避するのは、.comより前のすべての文字がキリル文字だからだ。これはラテン文字とキリル文字の明白な混在ではなく、単一文字体系のラベルである。
Chromiumは許可文字セットも維持している。危険または混同を招く表示に関連するさまざまなUnicodeブロックや個別のコードポイントを除外する。аррӏө.comの文字は、実在する言語で使われる正当な文字でもあるため、引き続き使用対象となる。
その後、複数の対象を絞ったチェックが続く。Chromiumは、関連する国別ドメイン以外でアイスランド語のthornとethを制限する。アゼルバイジャン語のschwaを制限し、カタルーニャ語の中点には特定のルールを適用する。これらの制限はいずれも、概念実証におけるキリル文字列には対処していない。
最も関連性の高い防御策は、Chromiumの文字体系全体の類似文字チェックだ。これは、すべてがラテン文字に似たキリル文字で書かれたラベルを探す。
Chromiumは、広く議論された2017年の実証の後、この保護を導入した。セキュリティ研究者のXudong Zheng氏は、ブラウザが実際のアドレスの視覚的なコピーに近い形で表示する、apple.comの全キリル文字版を登録した。
ChromiumはChrome 58で対応した。この文字体系全体のチェックは、ラテン文字に似た29個のキリル文字の集合を識別する。単一文字体系ラベルのすべての文字がこの集合に属する場合、ChromiumはドメインをPunycodeとして表示できる。
この防御は2017年版を捉える。しかし、新しい変種はөが列挙された29文字に含まれないため捉えられない。ラベル全体は依然として「apple」に似ているにもかかわらず、集合外の文字が1つあるだけで文字体系全体の条件が成立しなくなる。
この文字は人工的に作られた記号ではないため、ブラウザはどこかで許可する必要がある。キリル文字のөはカザフ語、モンゴル語、タタール語などで使用される。これをあらゆる場所でブロックすれば、正当な話者にとっての使いやすさを損なうことになる。
次にChromiumは、保護対象ドメインに対してスケルトン比較を行う。スケルトンは、視覚的に関連する文字を正規化された表現へと縮約し、ソフトウェアが既知の名前と比較できるようにする。
この処理は有用だが、人間の視覚を完全に再現することはできない。この場合、өを横切るバーは正規化後も残る。その結果得られるスケルトンは、期待されるラテン文字の「e」ではなく、「o」と結合記号に基づく形式で終わる。
この違いにより、apple.comのスケルトンとの完全一致は阻止される。コンパクトなブラウザインターフェースでは見えにくくなる小さな記号1つであっても、計算上の結果を変えるには十分だ。
ラテン文字の事例は、関連する弱点を示している。研究者らは、フック付きラテン文字ƙのような文字を用い、OktaやNikeなどの名称における「k」を模倣した。アクセント付きラテン文字ドメインは一般的かつ正当なため、Chromiumはラテン文字に対して広範な文字体系全体の警告を適用できない。
Chromiumはその代わりに、著名ドメインをまとめたリストに対して、より強力なスケルトン保護を与えている。HIBSは、このリストに8,462件の名前があり、そのうち836件がより優先度の高いグループに属することを確認した。しかし、余分な記号を残す文字は、正確なスケルトン一致を妨げる可能性がある。
Chromiumの表示ガイダンスは、根底にあるバランスを認めている。ChromeはIDN表示ルールが同形異義語リスクを識別した場合にPunycodeを表示するが、ASCII以外のアドレスをすべて敵対的なものとして扱うことは避けている。
このバランスにより、Chromium IDNスプーフィングは単純なブラックリスト問題ではなく、分類問題となる。新しいルールはすべて、正当な国際化ドメイン名を読めないエンコード文字列に変えずに、悪意ある類似性を捕捉しなければならない。
ブラウザ警告は第2の防御を提供するが、限界もある
Unicodeで表示されるドメインもナビゲーションチェックの対象となるが、そのチェックは完全一致、名前の長さ、訪問者の履歴に依存する。
Chromiumは、アドレス表示とナビゲーション時の保護を分離している。最初のシステムは、アドレスバーでホスト名がどのように見えるかを決定する。2つ目のシステムは、ユーザーが移動した後に訪問を中断したり、注記を表示したりできる。
Chromiumの類似ドメイン用ナビゲーションコンポーネントは、訪問先アドレスを人気ドメインやユーザーが定期的に訪れるサイトと比較する。一致の種類に応じて、Chromeは全画面のインタースティシャル、またはより控えめなSafety Tipを表示できる。
類似ドメイン警告の設計では、これらのチェックをGoogle Safe Browsingに加わる追加の層として説明している。人気度とユーザーの過去の利用状況は、ブラウザが疑わしい代替候補を識別するための参照点となる。
HIBSによると、優先度が最も高い836ドメインのいずれかとの完全なスケルトン一致では、インタースティシャルが表示される。別のバンドル済みドメインとの完全一致では、Safety Tipが表示される場合がある。
ブラウザは、ユーザーが十分な頻度で訪れるサイトも考慮する。新しいアドレスがそうした利用実績のあるサイトの1つに完全に似ている場合、Chromiumはナビゲーションをブロックし、訪問者が馴染みのあるドメインを開くつもりだったかを尋ねることができる。
ニアマッチへの対応はより限定的だ。Chromiumは、文字が1つ挿入、削除、置換されたスケルトンを検知できる。また、隣接する文字同士の入れ替えも1回まで認識できる。
こうした比較は一律には適用されない。研究によると、ニアマッチテストはトップレベルドメインの前にある対象ラベルが5文字未満の場合、そのチェックを省略する。短い名称を持つブランドにとって、これは重要だ。
ƙを使ったOktaの類似ドメインは実際の名称から1文字の編集距離にあるが、「okta」は4文字しかない。研究者らは、このため関連するニアマッチチェックの対象としては短すぎるとしている。
Appleの例が失敗する理由は異なります。そのスケルトンは、ө が「o」と保持されたバーに正規化されるため、apple.com との差が2編集分になるからです。近似一致の比較では、許容される編集は1回のみです。
その結果、テスト対象のドメインはUnicodeで表示され、類似ドメインに関する警告なしに読み込まれました。HIBSによれば、本物のAppleサイトを定期的に訪れていたユーザーでも、この挙動は変わりませんでした。
これらの調査結果は、アクセスを取り巻くあらゆる保護機能を完全に監査したものとして解釈すべきではありません。Safe Browsing、脅威インテリジェンスフィード、エンドポイントソフトウェア、DNSフィルタリング、メールゲートウェイ、レピュテーションサービスは、依然として悪意あるドメインを検知できる可能性があります。
HIBSは、リモートの許可リスト、レピュテーションチェック、特定のリダイレクト動作など、一部の変数も評価から除外しました。そのため、武器化されたサイトは、この概念実証で検証されなかった別の防御策に遭遇する可能性があります。
逆もまた同様です。新たに作成されたフィッシングドメインは、当初はレピュテーションデータがほとんどない場合があります。攻撃者は、自動システムがインフラを分類する前、または防御側がテイクダウンを完了する前のこの時間帯をしばしば悪用します。
これが、複数の保護策が存在する場合でもこのエッジケースが重要である理由です。多層防御は、失敗が相互に独立している場合に最も効果を発揮します。ここでは、複数のチェックが密接に関連したスケルトン表現とドメインリストに依存しているため、慎重に選ばれた1文字が複数の判断に影響を与え得ます。
履歴ベースの保護は、2人のユーザーが異なる扱いを受ける可能性も意味します。保護対象サービスを定期的に訪れるユーザーの場合、ブラウザには比較対象となる既知のドメインがあります。初めての訪問者には、組み込みの人気サイトリストしかない場合があります。
この違いは、採用サイト、地域銀行、業務ソフトウェア、サプライヤーポータルにとりわけ重要です。従業員は、一度も訪れたことのないサービスへのリンクを受け取る可能性があり、その場合、ブラウザには比較に使える個人の閲覧履歴がほとんどありません。
最も安全な結論は、Chromiumが保護をまったく提供していないということではありません。そのルールは、多くの一般的な置換をユーザーに届く前に阻止します。ここから得られる教訓は、アドレスバーの見た目や警告が表示されないことだけでは、真正性を確立できないということです。
IDNホモグラフ攻撃はアドレスバーを超えて広がる
ブラウザは表示面の一つにすぎず、欺瞞的なドメインはメール、メッセージングアプリケーション、文書、検索結果を通じてユーザーに届き得ます。
IDNホモグラフ攻撃は、別の識別子になりすますために、見た目が似た異なる文字を使用します。タイポスクワッティングは、単純なスペルミスや視覚的に紛らわしい文字を含め、正規ドメインと混同しやすい代替ドメインを登録する、より広い行為です。
今回の研究は、これらのカテゴリーが重なる地点に位置します。対象ドメインは従来型のキーボード入力ミスではありませんが、その視覚的な類似性は、素早い読解、小さな画面、見慣れたブランドの形状を悪用できます。
メールでは、特に難しい引き渡しが生じます。Chromiumのアドレス規則は、ブラウザのインターフェースで描画されるホスト名を保護します。一方、ウェブメールアプリケーションがメッセージヘッダー内に配置するUnicodeテキストを自動的に制御するものではありません。
HIBSは、ウェブ版GmailとOutlookで20件の国際化送信者ドメインをテストしました。研究者らによると、Gmailは20件すべてをUnicodeで表示し、その中にはChromiumのアドレスバーでPunycodeとして表示されるドメインも含まれていました。
テストによれば、Gmailは別個の mailed-by フィールドにエンコード済みの形式を保持していました。大半の受信者は、技術的な配送情報を展開するよりも、目立つ送信者行を確認する可能性が高いでしょう。
研究者らのテストでは、ウェブ版Outlookは逆のアプローチを取りました。café.com や zürich.com のような一般的な国際化ドメインを含め、20件すべての送信者ドメインをASCII互換ラベルとして表示しました。
どちらのアプローチも、根底にあるトレードオフを完全には解決しません。すべてをデコードすれば、ユーザーは国際化アドレスを読みやすくなりますが、視覚的な曖昧さは残ります。すべてをエンコードすれば差異は明確になりますが、正当な多言語アドレスが見慣れず解釈しにくくなります。
メッセージングアプリケーションや文書にも、同じ隔たりが生じ得ます。プラットフォームは、ユーザーが選択した宛先をブラウザが受け取る前に、Unicodeリンクを通常のテキストとして描画できます。ユーザーはある表示を評価し、その後で別のセキュリティシステムを通じて遷移します。
検索結果と広告は、さらに別の経路を加えます。欺瞞的なドメインは、見慣れたブランディングやコピーされたページタイトルと並んで表示される可能性があります。アドレスがわずかに異なっていても、周囲の文脈がユーザーに視覚的なパターンを補完させることがあります。
QRコードでは、スキャンが行われるまで表示先がほぼ完全に見えなくなります。モバイルブラウザではホスト名に使えるスペースも少なく、インターフェースは完全なアドレスよりページタイトルを強調する場合があります。
Unicode Consortiumは、紛らわしいIDNに対して複数の防御策を推奨しています。これには、許可される文字レパートリーの制限、危険なスクリプト混在の防止、文脈に応じた言語制約の適用、既存ラベルに似た登録の阻止が含まれます。
その IDN security guidance も、重要な留保を強調しています。Unicodeの紛らわしい文字が占める割合は、フィッシング全体のごく一部にすぎません。secure-brand-login.com のような単純なドメインの方が依然として一般的で、特殊な文字は必要ありません。
この文脈は、今回の調査結果が、Unicodeがオンライン詐欺の大半を生み出したという主張になることを防ぎます。攻撃者は通常、機能する中で最も低コストな手法を選びます。見慣れた単語、誤解を招くサブドメイン、盗まれたアカウント、侵害された正規サイトの方が、高度なIDNを構築するより容易な場合があります。
しかし、発生頻度が低いからといって、高価値の標的に対するリスクがなくなるわけではありません。アイデンティティプラットフォーム、金融サービス、クラウドコンソール、従業員ポータルは、攻撃者にとって価値の高い認証情報を提供します。視覚的になりすましの精度が高ければ、追加の手間をかける価値があります。
国際化そのものが欠陥なのではありません。インターネットは、基本ラテン文字以外で書かれた名前をサポートしなければなりません。こうしたアドレスをすべて敵対的なものとして扱えば、正当なユーザーや企業に負担を転嫁することになります。
未解決の問題は、各防御策がどこで機能すべきかです。ブラウザは表示とナビゲーション警告を制御します。レジストリは登録可能なラベルを制御します。メールサービスは送信者の表示を制御します。ブランド所有者は疑わしい登録を監視し、セキュリティチームはそれらをフィルタリングして調査します。
どの参加者も、完全な攻撃経路を把握しているわけではありません。この分断により、あるインターフェースでは拒否されるドメインが、別のインターフェースでは説得力を持って見えることがあります。
レジストリはChromiumのIDNスプーフィング対策をブラウザ任せにできない
最も持続性のある防御はナビゲーション前から始まりますが、レジストリのポリシーは言語やトップレベルドメインごとに依然として分断されています。
レジストリが登録を許可しない限り、ドメインは独立したウェブサイトやメールボックスを支えられません。したがって、レジストリの統制は、ブラウザが表示方法を判断する前に、欺瞞的な名前を阻止できます。
国際化ドメインのポリシーでは、一般にIDNテーブルが使用されます。これらのテーブルは、トップレベルドメインが受け入れるUnicode文字と、特別な扱いを必要とする組み合わせまたは異体を定義します。
Unicode Consortiumは、紛らわしいラベルをバンドルするかブロックすることを推奨しています。バンドルでは、関連する異体を同じ登録者に割り当てます。ブロックでは、あるラベルの存在を許可する一方で、混同を招く代替ラベルの登録を防ぎます。
ICANNの IDN implementation guidelines は、サイバースクワッティングと消費者の混乱を減らすことを目的とした一般的な期待値を定めています。実際のポリシーは、レジストリごとに対応する言語、スクリプト、地域の要件が異なるため、依然として異なります。
.com レジストリは、HIBSの概念実証における登録を許可しました。これは、.com があらゆるUnicodeシーケンスを受け入れることを意味するものではありません。テストされた文字と組み合わせが、適用される登録ルールに適合していたことを意味します。
HIBSはまた、2026年10月にICANNのCentralized Zone Data Serviceを通じて取得した .com ゾーンファイルを分析しました。研究者らは、委任された .com 名を167,226,216件と数え、そのうち733,509件がIDN形式で表現されていました。
その手法では、IDNを、視覚的に似ている委任済みASCIIドメインと関連付けました。その結果、133,953件の異なるASCII名を対象とする161,894組の類似ドメインペアが得られました。
これらの数値は、悪意あるドメインの件数ではありません。研究者らは、視覚的なペアが防御目的の登録、多言語ウェブサイト、または無関係な組織を表す可能性があると明確に注意を促しています。
この区別は不可欠です。アクセント付き文字を含むドメインは、偶然にASCII名に似ている場合があります。所有者、コンテンツ、DNSの挙動、証明書、メール設定、リダイレクトは、悪意を示すより強い証拠となります。
それでも、この規模は、ブラウザのリストが関連するすべての標的を列挙できない理由を示しています。Chromiumの組み込み保護は数千の著名な名前をカバーしていますが、.com ゾーンには、なりすましの標的になり得る何百万もの企業や組織が含まれます。
小規模企業は特にさらされやすい可能性があります。こうした企業のドメインは世界的な人気リストに載りにくい一方、顧客は会社名を冠した請求書、サプライヤーポータル、パスワード再設定メッセージを信用する可能性があります。
レジストリは、新たに特定された文字を特定の文脈で禁止することで対応できます。この手法は一つのエッジケースを閉じられますが、その文字に依存する有効な単語やコミュニティも排除しかねません。
より精密なポリシーでは、言語固有の関係に基づいて異体を定義できます。しかし、視覚的な類似性は、フォント、サイズ、隣接する文字、読者の慣れに左右されます。英語話者にとって明白に見えるシーケンスが、別の言語では正当な単語である場合があります。
防御的な登録も別の選択肢です。ブランドは想定される異体を登録し、本物のドメインへリダイレクトできます。Chromiumのナビゲーションコードは一部の安全なリダイレクトを認識するため、本物の組織が管理する異体での警告回避に役立ちます。
この戦略は完全には拡張できません。Unicodeには多くの潜在的な置換があり、登録ポリシーもトップレベルドメイン間で異なります。考えられるすべての類似ドメインを購入すれば、継続的なコストが生じ、それでも隙間は残ります。
監視はより広い範囲をカバーします。セキュリティチームは、重要なドメインに似た名前について、新規登録、証明書発行、DNS変更、ホスティングの挙動を監視できます。早期検知は、攻撃が多くの人に届く前のテイクダウン要請とブロックを支援します。
組織は、ブラウザ外の高リスクなワークフローも保護すべきです。パスワードマネージャーは認証情報を正確なオリジンに照合するため、類似ドメインで自動入力する可能性が低くなります。パスキーは認証を正規サイトのドメインに結び付け、従来型の認証情報フィッシングに耐性を持ちます。
支払いやアカウント復旧を扱う従業員には、リンクの見た目に依存しない検証経路が必要です。既知のブックマーク、管理されたアプリケーションポータル、独自に確認された連絡チャネルは、視覚的なドメイン認識への依存を減らします。
これらの対策は、ChromiumのUnicode類似ドメインだけに対応するものではありません。通常のスペルミス、誤解を招くサブドメイン、侵害されたメールボックス、複製されたログインページに対しても有効です。
したがって、圧力は複数の関係者に同時にかかります。Chromiumはヒューリスティクスを改善する必要があります。レジストリにはより強力な異体ポリシーが必要です。メールプロバイダーには、より明確な送信者表示が必要です。組織には、ユーザーが時にアドレスを読み違えることを前提とした統制が必要です。
次に何が起きるかが、この隔たりが本当に埋まるかを示す
この研究が持続的な防御につながるのか、それともパッチ適用済みの類似ドメインの歴史に新たな一例を加えるだけなのかは、3つの兆候によって決まります。
最初の兆候は、Chromiumのルール変更です。最も明確な対応は、キリル文字の ө、ラテン文字の ƙ、またはリスト外の1文字が全スクリプト評価を回避できる分岐ロジックに対処することでしょう。
単に2文字を追加すれば、公開された事例は阻止できます。しかし、それだけでは構造的な問題を解決できない可能性があります。目に見える記号や通常とは異なるスケルトンマッピングを持つ別の文字が、同じ結果を再現するかもしれません。
より包括的な修正として、追加のスケルトン変換によってレンダリング上の見た目を比較する方法も考えられる。しかし比較を緩めるほど、とりわけ正当な国際的名称に対する誤検知は増える。
Chromiumの公開コードとテストにより、このプロセスは検証可能である。セキュリティ研究者は、パッチが登録済みの実証例を遮断しつつ、影響を受ける言語の通常ドメインを維持できるかを調べられる。
2つ目のシグナルは、レジストリによる対応だ。更新されたIDNテーブルは、特定の文脈でこれらの文字を異体字として分類したり、既存のASCIIラベルを模倣する登録を防いだりできる。
表示上の差異が生じる前に欺瞞的な名称を阻止するため、レジストリの対応は記事の主要な判断を補強する。ブラウザだけのパッチでは、異なる表示規則を持つメールクライアントや他のアプリケーションで、これらのドメインが引き続き利用可能なままとなる。
3つ目のシグナルは、メール表示の変更だ。HIBSは、Gmailがテストしたすべての送信者ドメインをデコードして表示した一方、Outlookはエンコードされたラベルを表示したと報告している。今後のインターフェース変更では、両方の形式を公開したり、視覚的アイデンティティの混在をフラグ付けしたり、送信者が既知のドメインに似ている場合に警告したりする可能性がある。
メールは依然として、認証情報窃取や決済詐欺の自然な配信経路であるため、このシグナルは重要だ。Chromiumのパッチでは、Webアプリケーション内でテキストとして表示される欺瞞的な送信者名を防げない。
研究者は更新後、調査結果を再テストする必要もある。元の研究は、特定時点におけるブラウザの挙動、登録名、テスト用メールボックスを調べたものだ。すべてのChromiumビルド、OS、フォント、メールアプリケーションで文字が同一にレンダリングされることまでは示していない。
フォントの違いは、この錯覚を弱めることも強めることもある。より大きなサイズでは、өを横切る線には気づきやすい。コンパクトなアドレスバーや送信者欄では、この違いは目立ちにくくなる可能性がある。
報告された登録もまた、広範な悪用ではなく可能性を示すものだ。正確にこれらの文字を使ったフィッシングキャンペーンの公開証拠があれば、緊急性は高まる。そのような報告がないからといって、このギャップが無害だと示すわけではないが、リスクの優先順位には影響する。
ユーザーにとって、当面の教訓は「Unicodeを決して信用しない」というほど単純ではない。特に認証情報、支払い、アカウント復旧が関わる場合は、予期しない依頼を既知の経路で確認することが重要だ。ブックマークやパスワードマネージャーは、視覚的な確認だけよりも優れた基準となる。
管理者は、最も重要なドメインを棚卸しし、それらに似た登録を監視すべきだ。機密システムにはフィッシング耐性のある認証を求める。新しい取引先情報や支払い情報は、通常のメール作業ではなく検証イベントとして扱うべきである。
プロダクトチームは、アプリケーションが国際化された送信者アドレスやリンクをどのように表示するかをテストすべきだ。エンコード形式へアクセスできないまま親しみやすいUnicode名だけを表示すると、有用な証拠が隠される可能性がある。Punycodeだけを表示すると、正当な国際的アイデンティティに不必要な負担をかけることがある。
ChromiumのIDNスプーフィング防御は依然として堅固だが、この研究は堅固であることが完全であることを意味しないと示している。ブラウザは、明白な混在スクリプトの置換や既知の全スクリプト型のトリックを遮断したうえで、ナビゲーション時に人気のある、または見慣れた宛先を確認する。
慎重に選ばれた文字は、急いでいる人が見る印象を変えずに、機械による比較だけを変えられる。この差はコード上では小さいが、名称を認識することに信頼が依存する場面では重要である。
今後数か月で、Chromium、レジストリ、メールプロバイダーがこれらの例をリストへの個別追加として扱うのか、それとも各層に異なる前提が必要である証拠として扱うのかが明らかになるだろう。それまで組織は、自社ドメインをテストし、オリジンに紐づく認証を強化し、タイポグラフィだけを根拠にセキュリティ判断をユーザーへ求めることをやめるべきだ。
