【ITニュース解説】Node.js OTP Defense: List User Sessions and Revoke One Safely

ユーザーセッションの管理は、Webアプリケーションのセキュリティにおいて非常に重要な要素であり、特にワンタイムパスワード（OTP）認証を導入する際には、従来の認証システムとは異なる新たな脅威モデルに備える必要がある。セッション管理を単なるアカウント履歴の表示機能と捉えるのではなく、不正利用を制御するための防御面として設計することが求められる。

まず、OTP認証を導入するシステムでは、「OTPの失敗数が増加した」というアラートだけでは不十分である。このアラートは表面的なものであり、実際のシステム侵害は静かに進行している可能性がある。本当に警戒すべきは、OTP検証の成功と、それによって作成されるセッションの間に異常な関係が見られる場合だ。例えば、一つの電話番号から大量のセッションが生成されたり、一つのネットワークから多数のアカウントのOTPが検証されたり、通常の利用パターンと著しく異なるセッション作成が観測されたりする状況である。これらの異常は、総ログイン数のダッシュボードだけでは見過ごされがちであり、OTP検証とセッション作成の間のギャップに注目することが重要になる。

OTP認証が導入されると、攻撃者はボットなどを用いて、一時的な認証コードの成功を利用し、無制限に永続的なセッションを作成しようとする脅威が生じる。これに対処するためには、アカウントあたり、またはリスクの境界ごとに新しいセッションの作成数を制限し、OTP検証後にはセッション識別子を更新し、保管する識別子はハッシュ化することが不可欠である。さらに、不審なセッション無効化の要求には、最近の再認証を必須とすることも対策となる。

セッションの安全な管理には、いくつかの独立した制御を組み合わせることが効果的だ。一つだけでは盲点が生じる可能性があるからである。具体的には、OTPコードのリクエストや検証の試行を、アカウント、送信先（電話番号など）、ネットワーク境界、デバイス情報といった複数の側面から制限（スロットリング）する。また、各アカウントが同時に保持できるアクティブなセッション数を制限し、古いセッションを自動的に無効化するルールを設けることも重要である。セッション識別子は、OTP検証が成功した後に新しく発行し、ユーザーの権限が変更された際にも再度更新することで、過去のセッション情報が不正に利用されるリスクを低減する。そして、純粋なリクエスト数だけでなく、OTP検証の成功と実際に作成されたセッションの比率を監視し、異常を検知する仕組みが必要となる。これらの制限は、開始当初は保守的に設定し、誤検知をレビューしながら調整していくことが望ましい。ログイン時のわずかな手間は、深夜に攻撃者の大量ログインが成功していたことに気づくよりはるかに良い選択である。

セッションの無効化（revoke）は、単にブラウザのクッキーを削除する操作ではなく、サーバーサイドの状態を確実に変更する「状態遷移」として実装する必要がある。なぜなら、無効化したい対象のデバイスが既に手元にない可能性があり、ブラウザ側の操作だけでは対処できないからである。そのため、サーバー側でセッションの記録を保管し、認証済みのユーザー自身のセッションのみを表示し、無効化はアトミックな（分割できない）状態変更として実行され、保護されたすべてのリクエストでその状態変更が強制されるようにする。

セッション情報は、内部的なセッションID、ユーザーID、トークンのハッシュ値、作成日時、最終利用日時、有効期限、そして無効化された日時、デバイスなどの粗い表示用メタデータをサーバー側のデータベースに保存する。この際、ユーザーを識別するためのトークン（いわゆるベアラートークンや生のクッキー値）はデータベースに直接保存せず、セキュリティのためにハッシュ化された値を保存する。IPアドレスはユーザーの識別に使うべきではない。表示するデバイス情報は、ユーザーエージェント文字列から取得した「Chrome on Windows」のような抽象的なもので十分であり、不正確な位置情報を表示すると、ユーザーが誤って自分のセッションを無効化してしまう可能性があるため注意が必要だ。

セッションを無効化する操作は、データベーストランザクションを用いて、対象のセッションIDとユーザーIDが一致する場合のみrevoked_at（無効化日時）フィールドを更新するというアトミックな処理で行うべきである。これにより、他のユーザーのセッションが誤って無効化されることを防ぎ、所有権の確認と状態変更が同時に行われるため、不正な割り込みを防ぐことができる。Go言語のコード例が示すように、SQLのUPDATE文でid = $1 AND user_id = $2のように条件を指定することで、この安全性を保証できる。この無効化がコミットされた後は、そのセッションIDを使ったリクエストが成功しないように、すべての保護されたリクエストにおいて、セッションが「無効化されていない」かつ「有効期限内である」ことをチェックする必要がある。このチェック結果をキャッシュする場合は、無効化の遅延時間が許容できる範囲にあるかを慎重に検討しなければならない。例えば、5分間のキャッシュは、「このデバイスからサインアウト」という操作が5分間は効果を発揮しないことを意味し、これはパフォーマンス設定ではなくインシデント対応の決定である。

セッションリストを表示する際には、活動中のセッションを予測可能な順序で並べ、現在使用中のセッションはサーバー側で認証されたセッションIDと比較してマークする。クライアント側からの「これは現在のセッションである」という情報を受け入れるべきではない。リストのIDはデータベースの内部識別子であり、クッキーの秘密値とは絶対に混同してはならない。現在のセッションを無効化する際は、状態をコミットし、クッキーをクリアしてログインページへリダイレクトするのが一般的だが、他のセッションを無効化する際は、呼び出し元のセッションは維持されるべきである。「自分以外のすべてのセッションからサインアウト」のような機能も、ブラウザ側で各セッションをループして無効化するのではなく、サーバー側でユーザーIDを指定し、現在のセッションを除外してアトミックに処理すべきである。

これらのセキュリティ機能は、開発プロセスにおいて徹底的なテストを必要とする。二つのユーザーを作成し、それぞれに複数のセッションを与え、あるユーザーが別のユーザーのセッションをリスト表示したり、無効化したりできないことを確認する。また、セッションの重複無効化、期限切れセッションの無効化、同時に発生する無効化リクエスト、現在のセッションの無効化、無効化処理中に既に進行中のリクエストがどうなるかなど、さまざまなシナリオをテストする必要がある。不正利用に対するテストも別途必要であり、一つの宛先に多数のOTPコードリクエストを送る、一つのネットワーク境界から多数のアカウントのコード検証を行う、成功したOTP検証の後に急速なセッション作成が続くといったケースをシミュレートし、システムが適切に反応するかを確認する。ログには、OTPコードや生のセッショントークン、完全なクッキーヘッダーといった機密情報を含めてはならない。

運用上の不変の原則は、「セッションの無効化トランザクションがコミットされた後、そのセッションで新たに承認されたリクエストは成功しない」という点である。この原則が守られているかを、無効化後に拒否されたセッションのカウンターや、無効化のコミットから最初のリジェクトまでの遅延時間分布を測定することで直接確認する。

この機能のデプロイは段階的に行うことが推奨される。まずセッションの読み取りパスをデプロイし、次に無効化機能、最後にセッション数の制限や不正利用対応を導入する。ロールバックが必要な場合でも、アカウントページからセッション管理機能を一時的に無効にすることは許容されるが、一度無効化されたセッションの有効性を元に戻すことは絶対に避けるべきである。セキュリティ状態は常に一方向にのみ（より安全な方向へ）進むように設計し、無効化の状態は常に維持し、リクエスト時のチェックも活動状態に保つ必要がある。

最終的に、ユーザーセッションのリスト表示機能は、所有権によるフィルタリング、アトミックな無効化、リクエストごとの強制チェック、監査イベント、そして不正利用の制限がすべて連携してテストされた上で初めて出荷可能となる。テーブルの見た目はシンプルでも構わないが、その背後にある制御は決して簡素であってはならない。OTPベースのECサイトの場合、セッション作成の異常アラートが最も重要であり、そのアラートがどのような条件で発火し、どのような次元でトリガーされ、レスポンダーがチェックアウト機能を中断することなく新しいセッションの作成を停止できるかを検証することが、機能リリースの最終的な判断基準となる。