認証の終焉と「IDの物理化」：WebAuthn/FIDO2が突きつけるセキュリティの地平
「パスワードは死んだ」——この言葉を耳にしてから久しいが、未だにレガシーな認証基盤の残滓が、我々のインフラの首を絞め続けている。XSS（クロスサイトスクリプティング）を駆使したセッションハイジャックや、巧妙なフィッシングによる認証情報の奪取。これらは依然として攻撃者の常套手段だ。
今回は、単なる「パスワードレス」というバズワードを超え、WebAuthn/FIDO2がなぜこれらWebの脆弱性を根本から無効化するのか、そのプロトコル深層とアーキテクチャ設計の観点から解体していく。
—
1. XSSとセッションの脆弱性：なぜ「証明」は盗まれるのか
反射型・格納型・DOM型を問わず、XSSの最終目的は常に「クライアントのコンテキストでのコード実行」だ。攻撃者がXSSを通じて狙うのは、document.cookie からのセッションID抽出である。
もし認証がWebAuthnに移行されていれば、話は変わる。WebAuthnは、認証プロセスそのものが「オリジン（Origin）」に強く紐付いている。たとえXSSによって攻撃者がクライアント側のスクリプトを操作できたとしても、FIDO2の認証器（Authenticator）は、ブラウザが提供するOrigin情報と、あらかじめ登録された公開鍵のペアが一致しない限り、署名を拒絶する。
つまり、「悪意のあるドメイン」から呼び出されたスクリプトは、正規のOriginと結びついた署名を生成できない。これは、従来のCookieベースの認証が抱えていた「認証情報の再利用性」という致命的な欠陥を、暗号学的に解決している。
—
2. WebAuthnのプロトコル深層：パケット構造と「Origin Binding」
WebAuthnの実装において、開発者が最も見落としがちなのは「RP ID（Relying Party ID）」の検証だ。
FIDO2の通信フローでは、ブラウザとAuthenticator間で ClientDataJSON がやり取りされる。この中には origin フィールドが含まれており、Authenticatorはこの値を厳密に検証する。
実装時の防衛アーキテクチャ（Node.js / Expressの例）
// WebAuthn 認証時のサーバーサイド検証ロジック
// 重要なのは、クライアントから送られてきたデータが想定通りのOriginかを確認すること
async function verifyAssertion(assertionResponse, expectedChallenge, expectedOrigin) {
const { clientDataJSON, authenticatorData, signature } = assertionResponse;
// 1. clientDataJSON をデコードし、Originをパースする
const clientData = JSON.parse(Buffer.from(clientDataJSON, ‘base64’).toString());
// 2. 厳密なオリジン検証（ここを怠ると、サブドメインや中間者攻撃の隙を突かれる）
if (clientData.origin !== expectedOrigin) {
throw new Error(“Origin mismatch: フィッシングサイトからのリクエストの可能性”);
}
// 3. 署名の検証
// ここで検証されるのは、ハードウェア内の秘密鍵によって生成されたデジタル署名であり、
// ネットワークを流れる「パスワード」ではない。
return await verifySignature(signature, authenticatorData, …);
}
この「Origin Binding」こそが、フィッシング耐性の根幹である。中間者（MITM）がプロキシを立てて認証を中継しようとしても、Authenticatorが期待するOriginとプロキシのドメインが一致しないため、署名は生成されない。
—
3. 次世代の脅威への備え：耐量子暗号（PQC）への移行
今、我々セキュリティアーキテクトが直視すべきは、量子コンピュータの登場によるRSA/ECDSAの無力化だ。FIDO2規格もこの未来を想定しており、現在、次世代の認証プロトコルでは耐量子アルゴリズム（Lattice-based cryptography等）の組み込みが議論されている。
現時点でのガードレイル設計としては、以下を推奨する。
1. 疎結合な認証器の管理: 認証器（YubiKey等）のファームウェア更新を追跡し、将来的にPQC対応のアルゴリズムへ移行可能なアーキテクチャ（複数の署名アルゴリズムをサポートするRP側の実装）を構築しておくこと。
2. 生成AIによるプロンプトインジェクション対策: WebAuthnの登録プロセスにAIアシスタントを組み込む場合、認証フローとAIの推論フローを完全に分離し、認証器の署名検証ロジックを「AIが触れない独立した検証サービス」として隔離することが不可欠だ。
—
結びに代えて：泥臭い現場の教訓
私が多くのインシデントを見てきて痛感するのは、「技術は脆弱性を埋めるが、設計は脆弱性を生む」という事実だ。WebAuthnを導入しても、その実装を担うAPIサーバのセッション管理が甘ければ、結局はXSSの餌食になる。
我々エンジニアが追求すべきは、単なる「認証のパスワードレス化」ではない。「ユーザーの操作が、いかなる文脈（コンテキスト）で実行されているか」を、暗号学的な署名によって証明し続けるシステム設計である。
セキュリティは銀の弾丸を求めるゲームではない。プロトコルの仕様を読み込み、パケットの挙動を疑い、そして何より、攻撃者の「次の手」を常に先回りしてガードレールを敷く。この泥臭い積み重ねこそが、現代のWebアプリケーションを支える唯一の防壁なのだ。
次回の記事では、このWebAuthn環境下における「セッション固定化攻撃」のより高度な対策について、メモリダンプ解析の観点から掘り下げていく。ご期待いただきたい。
コメント