Modern Frontend CVEs

対象CVE: GHSA-7rqj-j65f-68wh

[重要セキュリティ情報] Auth.jsのメール正規化脆弱性 (GHSA-7rqj-j65f-68wh) とその対策

Auth.js(旧 next-auth)のメール/マジックリンク認証フローに、ホモグリフを利用したアカウント乗っ取りの可能性がある脆弱性が発見されました。本記事では、この脆弱性の詳細、影響範囲、そして日本のフロントエンドエンジニアが取るべき対策について解説します。

脆弱性の概要と技術的詳細

Auth.js(旧 next-auth)のメール/マジックリンク認証フローでは、ユーザーが入力したメールアドレスのバリデーションがUnicode正規化(例: NFKC/NFKD)よりも先に行われるという問題がありました。この不適切な処理順序が、攻撃者がホモグリフ(見た目は似ているが異なるUnicode文字)を悪用する余地を生み出します。

具体的には、通常の `@` (U+0040) ではないが、NFKC/NFKD正規化によって `@` に変換されるような特殊なUnicode文字がメールアドレスに含まれている場合、最初のバリデーション(例: メールアドレス内に `@` が1つだけ存在するか)をパスしてしまうことがあります。

その後、マジックリンクを送信する段階で、多くの国際化メールに対応したメール送信ライブラリやサービスが、このアドレスに対してUnicode正規化を適用します。その結果、元のアドレスには存在しなかった2つ目の `@` 文字が生成され、メールシステムが意図しない別のアドレスにマジックリンクを誤配送してしまう可能性があります。これは「正規化前のバリデーション」というセキュリティ上のアンチパターンに該当します。

影響を受けるプロジェクトの条件

以下の条件をすべて満たす場合に、皆さんのプロジェクトがこの脆弱性の影響を受ける可能性があります。ご自身のアプリケーション構成をご確認ください。

1. `next-auth` が `4.0.0` 以上 `4.24.14` 未満、または `@auth/core` が `0.1.0` 以上 `0.41.3` 未満のバージョンを使用している。

2. メール/マジックリンク(パスワードレス)プロバイダーを有効にしている。

3. 組み込みのデフォルト識別子正規化機能(`normalizeIdentifier` をカスタマイズしていない)を使用している。

4. `sendVerificationRequest` の実装において、メール送信ライブラリやサービスが受信者アドレスにUnicode正規化を適用するもの(多くの国際化メール/SMTPUTF8対応の送信者が該当)を使用している。

なお、メールプロバイダー自体を使用していない場合や、独自に `normalizeIdentifier` を実装して非ASCII文字の拒否やNFKC正規化を先行して行っている場合は、この脆弱性の影響は受けません。

脆弱性による影響

この脆弱性の最も深刻な影響は「アカウント乗っ取り」です。攻撃者は被害者のメールアドレスを知っていれば、ホモグリフを含むアドレスでマジックリンクをリクエストできます。この不正なリクエストにより、正規化後のアドレスが攻撃者管理下のメールボックスに誤って配送された場合、攻撃者はそのリンクを使用して被害者としてログインできてしまいます。

この攻撃は被害者の操作を一切必要とせず、攻撃者が認証フローを開始するだけで実行され得るため、非常に危険度が高いと言えます。

対策と推奨される対応

根本的な解決策は、Auth.js または `@auth/core` を修正済みバージョンにアップグレードすることです。修正バージョンでは、アドレスのバリデーションを行う前にUnicode (NFKC) 正規化が適用されるため、ホモグリフによる二重 `@` の問題が事前に検出・拒否されます。アップグレード後、アプリケーションコードの変更は不要です。

執筆時点では正確な修正バージョンがまだ公開前ですが、公式アドバイザリ(GHSA-7rqj-j65f-68wh)が更新され次第、速やかに最新バージョンへのアップグレードを強く推奨します。

緊急時のワークアラウンド

すぐにアップグレードが難しい場合は、以下のいずれかのワークアラウンドを適用してください。これらは一時的な対応であり、最終的にはバージョンアップが必要です。

1. **カスタム `normalizeIdentifier` の実装**: メールプロバイダーの設定にカスタムの `normalizeIdentifier` 関数を渡します。この関数内で、バリデーションを行う前に `identifier.normalize("NFKC")` を呼び出し(小文字化やトリムも忘れずに)、正規化後に `@` が正確に1つだけ含まれているかを確認し、それ以外のアドレスは拒否するように実装します。

2. **非ASCII文字の拒否**: もし皆さんのユーザーベースが国際化されたメールアドレス(非ASCII文字を含むアドレス)を必要としない場合、メールアドレスのローカルパートまたはドメイン部分に非ASCII文字が含まれているアドレスを完全に拒否する、という実装も検討できます。これにより、ホモグリフ問題の発生源を断つことができます。

まとめ

Auth.js(または next-auth)をご利用の日本のフロントエンドエンジニアの皆様は、この脆弱性がクリティカルなアカウント乗っ取りにつながる可能性があることを認識し、速やかにバージョンアップまたはワークアラウンドの適用を検討してください。セキュリティアドバイザリの更新を注視し、常に最新の情報を確認して、安全なアプリケーション開発を心がけましょう。

本脆弱性を発見・報告してくださった @kakashi-kx 氏に心より感謝申し上げます。

← ブログ一覧に戻る