WebAuthn/FIDO2の防壁を突破する「Origin」の虚影：実務者が語る実装の深淵
多くのエンジニアは「WebAuthnを導入すればフィッシングは防げる」と信じている。だが、セキュリティアーキテクトの視点から言えば、それは半分正解で、半分は致命的な誤解だ。公開鍵認証は「何と戦っているのか」という本質を理解しなければ、ただの“高価なパスワード”に成り下がる。
特に、WebAuthnの心臓部である「Origin検証」を疎かにした実装は、攻撃者にとっての格好の餌食だ。今日は、ブラウザのブラインドスポットを突く攻撃ロジックと、その防御を担保するためのアーキテクチャについて、現場の泥臭い知見を交えて紐解いていく。
—
1. なぜ「Origin検証」が唯一無二の防波堤なのか
WebAuthnが従来のパスワード認証と一線を画すのは、クライアント（ブラウザ）が「現在接続しているサイトのOrigin」と「認証器が記憶している登録時のRP ID」をバインドし、暗号学的に証明する点にある。
攻撃者は、巧妙に偽装したフィッシングサイトへユーザーを誘導する。もしバックエンド側でこの検証を厳格に行っていない場合、あるいはRP ID（Relying Party Identifier）の設計がずさんである場合、攻撃者は「正当なRP IDを要求するプロキシ」を介在させることで、認証器から署名を引き出すことが可能になる。
ブラウザの裏側：APIが強制する「Same-Origin Policy」
ブラウザはnavigator.credentials.create()やget()が呼ばれる際、呼び出し元のOriginを厳格にチェックする。しかし、サーバー側がこれを受け取る際、originパラメーターをロギングするだけで済ませていないか？
検証は単なる「確認」ではなく、「期待されるRP IDと一致するか」という数学的等価性の確認でなければならない。
—
2. サーバーサイドにおける実装の「落とし穴」
多くのWebフレームワーク用ライブラリは、rpIdの検証をオプションにしている場合がある。ここで発生する脆弱性の多くは、allowCredentialsやchallengeの生成以前の、「RP IDの誤設定」に起因する。
不適切なRP ID設定の例
例えば、ドメイン app.example.com で認証を行いたいのに、RP IDを親ドメインの example.com に設定するケースだ。これにより、攻撃者がサブドメイン attacker.example.com を乗っ取った場合、ブラウザのセキュリティ境界が緩み、認証フローが流出するリスクを許容してしまう。
// 【脆弱な実装例】検証をスキップ、またはドメインを広げすぎている
const options = {
challenge: Uint8Array.from(challenge, c => c.charCodeAt(0)),
rp: {
name: “My Secure App”,
id: “example.com”, // 危険：親ドメインを指定すると範囲が広すぎる
},
// …
};
// 【検証時の鉄則】サーバーサイドでのチェックロジック
// 以下の比較を疎かにしてはならない
if (clientDataJSON.origin !== “https://app.example.com”) {
throw new SecurityError(“Invalid Origin: 期待されたOriginと一致しません”);
}
if (clientDataJSON.rpId !== “app.example.com”) {
throw new SecurityError(“Invalid RP ID: 認証器が主張するIDが不正です”);
}
—
3. 次世代の脅威：AI生成フィッシングとガードレイルの設計
今後、生成AIが個人の文体に合わせたフィッシングメッセージを自動生成する時代において、WebAuthnのOrigin検証は「最後の砦」から「最初の防衛線」へとシフトする。
防御層を強固にするためのアーキテクチャ設計として、以下の3点を推奨する。
1. Strict Origin Binding: 認証レスポンスを検証する際、originが期待する完全修飾ドメイン名（FQDN）と完全に一致することを確認する。サブドメインのワイルドカード許可は厳禁だ。
2. Attestation Statementの厳格評価: 特に高セキュリティが求められる環境では、noneアテステーションを受け入れず、信頼できるベンダーのルート証明書を用いた検証を強制する。これにより、エミュレーターや悪意のある仮想認証器を排除できる。
3. 量子耐性への備え: 現在のFIDO2/WebAuthnはECDSAやEdDSAに依存している。将来の耐量子暗号（PQC）移行を見据え、公開鍵のアルゴリズム選択を動的に変更できる抽象化レイヤーを認証バックエンドに設けておく必要がある。
—
4. チーフホワイトハッカーからの提言
コードは嘘をつかないが、設計者の慢心は嘘をつく。
WebAuthnを実装する際、開発者が陥る最大の罠は「ブラウザがやってくれるだろう」という性善説だ。ブラウザはあくまでユーザーエージェントであり、セキュリティの責任はサーバーサイドにある。
パケットの構造レベルで見れば、clientDataJSONはBase64エンコードされたJSON文字列に過ぎない。これをデコードし、その中身を正規表現ではなく、型安全なスキーマバリデーションで解析する。そして、何よりも「Origin」という文字列を、単なる識別子ではなく「信頼の境界線」として扱うこと。
もしあなたが現在、WebAuthnの実装レビューを行っているなら、まずは rpId の設定と、サーバーサイドでの clientDataJSON のパース処理を徹底的に叩いてみてほしい。そこに、脆弱性のシッポが隠れている可能性は極めて高い。
セキュリティは「完成」ではなく「継続的な戦術の修正」だ。この本質を理解したエンジニアこそが、次世代のデジタルインフラを守る真のアーキテクトになれる。
コメント