better-auth、別ユーザーでログインされる欠陥 1.7.7で修正
TypeScript向け認証ライブラリ better-auth に、特定の設定の組み合わせで、他人のメールアドレスを知っているだけで本人としてログインできてしまう欠陥が見つかりました。Magic Link、OAuthログイン、account.storeStateStrategy の database 指定をすべて使っているアプリが対象です。1.7.7 で修正されているため、該当する構成なら更新を急いでください。
急ぎ度: 至急
認証なしでネットワーク越しに既存ユーザーのセッションを得られる欠陥で、CVSSは9.1です。ただし発生には設定の条件がそろう必要があり、該当しない構成なら急ぐ度合いは下がります。
関係があるか
better-authを使ってログイン機能を作っており、Magic Linkと、ソーシャルログインまたはGeneric OAuthの両方を有効にしているアプリが対象です。さらに、account.storeStateStrategy を database にしている場合に限られます。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| better-auth(npm パッケージ) | 1.4.0-beta.18以上1.7.7未満。かつ下記の設定条件をすべて満たす場合 | 1.7.7 |
確かめ方
- 1導入版を確認します。
npm ls better-auth（pnpmならpnpm why better-auth、yarnならyarn why better-auth）で、1.4.0-beta.18以上1.7.7未満かどうかを見ます。モノレポでは、各アプリの依存関係も確認してください。 - 2認証の設定ファイルで、Magic Linkのプラグインを有効にしているか確認します。
- 3Magic Linkの
storeTokenがplainか、hashedの場合はverification.storeIdentifierもhashedかを確認します。hashedでもstoreIdentifierがhashedでなければ、この条件には当てはまりません。 - 4組み込みのソーシャルプロバイダー（GitHub、Googleなど）かGeneric OAuthを有効にしているか確認します。
何が起きたか
better-authは、Webアプリにログイン機能を組み込むためのライブラリです。この欠陥は、特定の設定を組み合わせたときに起きます。パスワードを使わずメールのリンクでログインする「Magic Link」の確認処理が、ソーシャルログインの途中で発行される内部の値を、Magic Linkの合言葉として受け入れてしまいます。攻撃者は、対象者のメールアドレスを知っていれば、そのメールボックスを操作できなくても、対象者としてログインできる可能性があります。
たとえるなら、クロークの預かり札と、会員確認用の札に同じ番号体系を使ってしまい、片方の札でもう片方の窓口を通れてしまう状態です。
技術的には、Magic Linkの検証用レコードとOAuthのstateが、保存先で同じ識別子に解決される場合があります。storeToken が plain の場合、または storeToken と verification.storeIdentifier がともに hashed の場合で、account.storeStateStrategy が database のときに起きます。このため、OAuthのログイン開始時に作られたstateをMagic Link側で使えてしまいます。弱点の種類はCWE-287（不適切な認証）です。
攻撃の流れ
-
1
対象の選定
攻撃者は、ログインしたい既存ユーザーのメールアドレスを把握します。
-
2
OAuth開始
ログイン前の状態のまま、そのメールアドレスでOAuthログインを開始し、内部のstateを受け取ります。
-
3
Magic Linkで提示
受け取ったstateをMagic Linkの確認に渡すと、有効な合言葉として扱われます。
-
4
セッション発行
メールの受信もプロバイダーでの認証もないまま、通常のセッションが発行されます。
どう悪用されるか
悪用に必要なのは、ネットワーク経由でアプリに接続できることと、対象者のメールアドレスを知っていることです。事前のログインも、利用者に何か操作させることも要りません。CVSSでは攻撃の難易度は低いとされています。
被害は2通りです。1つ目は、既存ユーザーとして通常のセッションを取得され、そのユーザーの権限でアプリを操作されることです。2つ目は、サインアップを許可している場合に、メール確認済みと誤って記録されたアカウントを作られることです。後者は、メール確認済みであることを前提にした招待や権限付与の判断に悪影響が出るおそれがあります。影響は機密性と完全性に及び、可用性への影響はないと評価されています。
今すぐやること
-
1
better-authを1.7.7に更新する
1.7.7で修正されています。更新後は、ログイン、Magic Link、ソーシャルログインの動作を確認してから本番に反映してください。ロックファイルを使っている場合は、ロックファイル側の版も1.7.7になっていることを確かめます。
npm ls better-auth -
2
自社の構成が条件に当てはまるか確認する
Magic Linkの有効化、
storeTokenとverification.storeIdentifierの値、OAuthプロバイダーの有無、account.storeStateStrategyの値を確認します。複数のアプリやサービスで使っている場合は、すべて洗い出してください。 -
3
更新までの間は、条件のどれかを外すことを検討する
影響を受けるのは条件がすべて重なる場合だけです。Magic Linkを一時的に無効にすることが、最も単純な回避策です。設定変更の影響は、更新前に検証環境で確かめてください。
-
4
不審なログインやアカウント作成を点検する
悪用が確認されたかどうかは公表されていません。念のため、普段と違う場所や時間のログイン、メール確認済みの状態で作られた見覚えのないアカウント、管理系の操作履歴を見直してください。不審なものがあれば、該当ユーザーのセッションを失効させます。
すぐ更新できないとき
すぐに更新できない場合は、影響が出る条件のどれかを外します。具体的には、Magic Linkを無効にする、OAuthのプロバイダーを無効にする、account.storeStateStrategy を database 以外にする、といった方法です。設定を変えるとログイン方法や保存形式に影響する可能性があるため、変更前に公式の告知とドキュメントを確認し、検証環境で動作を確かめてください。恒久対策は1.7.7への更新です。
背景
better-authのような認証ライブラリは、アプリ全体の入口を担当します。ここに欠陥があると、個々の機能を正しく作っていても、ログインの段階で他人になりすまされ、画面や権限の制御が意味を失います。そのため、認証まわりの欠陥は、影響の大きさから優先度が高くなりがちです。
Magic Linkは、メールで送ったリンクを開いた人を本人とみなす方式です。OAuthのstateは、ログインの開始と完了が同じ利用者の操作であることを確かめるための値です。本来は別の目的で使う値や識別子が、保存や照合の仕組みの中で取り違えられると、意図しない認証が通ってしまうことがあります。この種の「用途の違うトークンの混同」は、認証の実装で以前から注意されてきた弱点の一つです。今回は、設定によって保存先の識別子が重なることで起きています。
よくある質問
Q.better-authを使っていますが、Magic Linkは使っていません。影響はありますか。
Q.1.7.7に更新すれば、設定を変える必要はありますか。
Q.実際に攻撃は起きていますか。
Q.ソーシャルログインしか使っていないアプリは安全ですか。
まだ分かっていないこと
- 実際の攻撃で悪用されたかどうかは公表されていません。
- 1.7.7より前の版向けの修正が別途提供されるかどうかは、現時点で明らかになっていません。ベンダーの告知（GitHubのアドバイザリとリリースノート）で確認してください。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| better-auth | better-auth | — | — |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Better Auth is an authentication and authorization library for TypeScript. From 1.4.0-beta.18 until 1.7.7, deployments that enable Magic Link with storeToken set to plain, or with storeToken set to hashed and the global verification.storeIdentifier setting also set to hashed, enable a built-in social or Generic OAuth provider, and use account.storeStateStrategy set to database can accept an OAuth sign-in state value as a Magic Link token. These settings can cause Magic Link verification records and OAuth state to resolve to the same stored identifier, allowing an unauthenticated attacker to start OAuth sign-in for a known email address and redeem the returned state through Magic Link without controlling the mailbox or completing the provider callback. The attacker can obtain a normal session for an existing user, or create an account incorrectly marked as email verified when sign-up is enabled. This issue is fixed in version 1.7.7.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory github.com
- advisory github.com
- advisory nvd.nist.gov
- patch github.com
- patch github.com
- web github.com