ログイン画面に見慣れたロゴがあっても、正しいドメインとは限りません。 アドレスに文字が一つ増えていたり、ドットの位置が違ったり、別の文字体系の 文字が使われていたりします。パスワードを入力する前や、暗号資産 ウォレットの操作を承認する前に、この URL の本当の持ち主を確かめましょう。
タイポスクワッティングは、もっともらしい綴り間違いを利用します。 ホモグラフ攻撃は、フォントによって似て見える別の文字を使います。 たとえばラテン文字の「a」とキリル文字の「а」です。紛らわしいアドレスは 偽のログイン画面、不審なダウンロード、単に無関係なサイトにつながる こともあります。見た目だけで行き先の挙動は分かりません。予期しない ログインや取引の承認を求められたら、特に慎重に確認してください。
紛らわしいアドレスの四つの形
仕組みはそれぞれ違いますが、どれも無関係な行き先を見慣れたものに 見せかけます。以下は説明用の例です。似ているドメインがすべて悪質とは 限りません。
似て見える Unicode 文字。ラテン文字の「a」と キリル文字の「а」は別の文字ですが、よく似て見えることがあります。 国際化ドメイン名は DNS 上では ASCII 形式で表され、変換された ラベルは「xn--」で始まります。Unicode の セキュリティ標準 は、異なる文字体系間で紛らわしい文字を扱っています。ブラウザが Unicode と ASCII のどちらで表示するかは、その表示規則によります。
単純な綴り間違い。文字が増える、抜ける、 順序が入れ替わるだけで、別のホスト名になります。数字が文字に 似て見える場合もあります。すべて通常の ASCII 文字でも成立するため、 Unicode 用の対策だけでは防げません。
紛らわしいサブドメイン。「accounts.example.com.login.example.net」のホスト名は、その文字列 全体です。先頭に「example.com」が含まれていても、そのサイトの 一部にはなりません。登録可能なドメインを見分けるには、ホスト名と 公開サフィックスを確認します。たとえば「co.uk」は公開サフィックスで、 誰かが所有するドメインそのものではありません。これらは Public Suffix List にまとめられています。
末尾の違い。同じ名前でも、「.com」のサイトと 「.co」や「.shop」のサイトは別です。見た目を模倣することはできますが、 ロゴが同じで HTTPS 証明書が有効でも、分かるのはそのアドレスとの 通信が暗号化されていることだけです。表示された企業が所有している 証拠にはなりません。
似たドメインの作成と悪用
ドメインの候補を作る作業は自動化できます。オープンソースの dnstwist は、綴り間違い、似た文字、異なる末尾を使った候補を生成し、 名前解決できるか調べられます。自社ブランドを監視する側にも 役立つ道具です。ただし、似たドメインが登録されているだけで フィッシングに使われているとは判断できません。
偽サイトが本物の見た目を模倣することもあります。一部の フィッシングでは、ログイン操作を本物のサービスへ中継し、 条件が揃えば攻撃者がパスワードや使い捨てコードを受け取ります。 一方、パスキーによる認証は正規サイトの識別子とオリジンに結び付いています。FIDO Alliance の解説 にあるとおり、似せたドメインで正規サイト用の認証を成立させにくい仕組みです。 ただし、ログイン後に表示されるページや取引の安全まで保証するものではありません。
綴りや文字体系が変われば別のホスト名になる
登録されただけでは悪用の証拠にならない
ログインの防御力は認証方式によって異なる
ブラウザの表示と限界
ブラウザには国際化ドメイン名に対する防御があります。Chromium の表示規則 では、疑わしいラベルを Unicode の代わりに「xn--」形式で表示する 場合があります。Firefox も 独自の表示規則 に従って二つの形式を使い分けます。ブラウザやバージョン、ホスト名によって 表示は異なり、似たドメインが必ず本物と同じ姿で表示されるわけではありません。
「xn--」が見えたからといって不正とは限りません。正当な国際化ドメイン名も 同じ ASCII 形式を使います。逆に、ASCII だけの打ち間違いや紛らわしい サブドメインには、Unicode に関する手掛かりがありません。鍵のマークや HTTPS が示すのは表示されたホストとの暗号化通信であり、画面に書かれた 組織がそのホストを所有していることではありません。
メッセージの文脈も判断を誤らせます。知人や普段使うサービスから届いた ように見えても、リンク先は別かもしれません。ブラウザの警告は助けに なりますが、Google は Safe Browsing が危険なサイトを見逃したり、安全なサイトを誤って警告したりする可能性 を明示しています。重要なログインやウォレットの承認を求めるリンクなら、 メッセージとは別の経路でサービスを開いて確認してください。
URL を慎重に確かめる
ログイン、支払い、ダウンロード、取引の承認を求めるメッセージでは、操作前に行き先を確認します。以下の手順は判断材料を増やしますが、一つだけでページの安全性を証明するものではありません。
- 1
信頼できる入口から始める
保存したブックマーク、パスワード管理ツールに登録したサイト、 または別の方法で知っているアドレスを使います。メッセージ内の リンクで、そのメッセージの正しさを確かめないでください。 - 2
ホスト名全体を確認する
報告されたリンクを調べる必要があれば、開かずに URL 全体を 文字列として確認します。ホスト名とパス、クエリを区別し、 公開サフィックスを踏まえて登録可能なドメインを特定します。 URL の別の場所にブランド名があっても、所有者の証拠にはなりません。 - 3
IDN の手掛かりを過信しない
「xn--」が見えたら詳しく調べるきっかけになりますが、正当な 国際化ドメイン名でも使われます。普通に見える Unicode の ラベルにも確認が必要な場合があり、ASCII の綴り間違いには IDN 特有の手掛かりがありません。フォントを変えたり URL を テキストエディタに貼り付けたりしても、確実には判別できません。 - 4
いつもの経路からログインする
正当な依頼なら、サービスを自分で開いた先でも確認できる場合が ほとんどです。ブラウザのフィッシング警告は有効にしておきましょう。 対応するサービスでは、オリジンに結び付くパスキーは再利用可能な パスワードや使い捨てコードよりログイン時のフィッシングに強い対策です。 ただし、ページのほかの内容までは保証しません。
ページを見る必要がある場合
調査のため、不審なページの表示を確かめなければならない場合もあります。 Browser.lol の一時的なセッションなら、分析者の端末ではなく リモートブラウザでページを実行できます。サイトにはリモートブラウザの 出口アドレスが見え、分析者は画面を受け取るために Browser.lol に 接続します。保存済みプロファイルを読み込まず、本物の認証情報を入力せず、 ウォレットを接続したり操作を承認したりしないでください。 偽の入力欄に書いた内容は相手に渡り得ます。隔離環境も、ページや取引の 信頼性を判定するものではありません。
元のメッセージやトークン付きリンクは組織の規則に沿って扱います。 Browser.lol は法的な証拠に使うための録画やマルウェア判定を 自動で作成しません。閲覧タブを閉じただけではセッションの終了も 確認できません。明示的に終了し、実際に観察したことだけを記録してください。 調査全体の手順は 不審なリンクを慎重に調べる方法で説明しています。
