長時間のセッション維持を許容する場合の緩和策#
1. 脆弱性の概要/影響#
Webアプリケーションにおいて、
再ログインの頻度を減らしたいという利用者の要望や、業務の性質上長時間のログイン状態を維持したいという要件から、セッションタイムアウトを長めに設定したくなるケースは少なくありません。
しかし、セッションが長時間有効な状態にあると、何らかの原因でセッションが第三者に渡った場合に、そのセッションを悪用できる時間的猶予が広がり、不正アクセスや情報漏えいのリスクが高まります。
セッションが第三者に渡る経路としては、たとえばXSSやネットワーク上の盗聴によるセッションIDの漏えい、ログイン状態のままの端末の紛失・盗難、共有端末でのログアウト忘れによるセッションの残存などが考えられます。
いずれのケースにおいても、セッションが有効である間は、第三者が本人のセッションを悪用して、情報を閲覧したり、権限の範囲内で各種操作を行ったりする可能性があります。
また、セッションが長く維持されるほど、不正利用が可能な期間も長くなり、結果として被害が拡大するおそれが高まります。
2. 根本的な対策#
リスクを完全に排除する根本的な対策は存在しません。
セッションの悪用リスクを低減するためには、アプリケーションの性質や取り扱う情報の重要度に応じて適切なタイムアウトを定義し、サーバ側で確実に強制することが重要です。利便性を理由に無制限または過度に長いセッションを許容するのではなく、セキュリティと使いやすさのバランス、利用者の操作特性を踏まえてタイムアウト値を設定する必要があります。
セッション管理では、少なくとも以下の2種類のタイムアウトを併用することが重要です。
アイドルタイムアウト(Idle Timeout)
- 最後の操作やHTTPリクエストから一定時間が経過した場合にセッションを無効化する仕組みです。NISTでは「Inactivity Timeout」とも呼ばれています。離席や操作の中断など、利用者が操作していない間の悪用を抑止する効果があります。
絶対タイムアウト(Absolute Timeout)
- 活動状態にかかわらず、認証または再認証から一定時間でセッションを無効化する仕組みです。NISTでは「Overall Timeout」とも呼ばれています。アイドルタイムアウトだけでは、攻撃者が定期的にリクエストを送ることでセッションを無期限に延命できるため、絶対タイムアウトで上限を設けることが必要です。
OWASPおよびNISTの文書では、タイムアウト値の目安として以下のような考え方が示されています。
OWASP Session Management Cheat Sheet#
アイドルタイムアウトについて、高価値アプリケーションでは2〜5分、低リスクアプリケーションでは15〜30分という、アプリケーションの重要度に応じた目安を挙げています。
NIST SP 800-63B#
AAL(Authentication Assurance Level)ごとの再認証要件として以下の時間を示しています。
| AALレベル | Overall Timeout | Inactivity Timeout |
|---|---|---|
| AAL1 | 30日以内 | 設定任意 |
| AAL2 | 24時間以内 | 1時間以内 |
| AAL3 | 12時間以内 | 15分以内 |
3. 緩和策#
いずれも一般的なセキュリティ対策ですが、セッションタイムアウトを長めに設定しなければならない場合には、以下のような仕組みを導入することで影響を緩和できます。
3.1 重要操作前・リスクイベント発生時の再認証要求#
重要な操作については、現在のセッションが有効であることだけを根拠に実行を許可しないことが望まれます。OWASP Authentication Cheat Sheetでは、パスワード変更やメールアドレス変更のような機微なアカウント情報の更新や、配送先変更のような重要な操作の前に、現在の認証情報による再確認を求めることを推奨しています。これにより、CSRFやセッションハイジャック、あるいは第三者が一時的に利用者の端末やブラウザへアクセスできた場合でも、重要操作まで連鎖的に実行されることを防げます。
再認証は、リスクの高いイベントが検知された際にも要求することが有効です。同Cheat Sheetでは、再認証の契機として、異常なログインパターンやIPアドレス・利用端末の変化といった不審なアカウントアクティビティを検知した場合などを挙げています。これにより、たとえセッションが継続中であっても、通常と異なる状況下では追加の本人確認を挟み、不正利用の継続を抑止できます。
あわせて、再認証後は既存セッションIDを無効化し、新しいセッションIDを発行すること(セッションIDのローテーション)も推奨されています。
3.2 ログイン状態の可視化・通知#
利用者自身がログイン状況を把握し、不審なセッションに気づいて対処できる仕組みを整えておくことも有効です。具体的には、アクティブなセッションの詳細をいつでも確認できるようにすること、不正なセッションを利用者または管理者が終了できるようにすることが挙げられます。OWASP ASVS 5.0(V7.5 Defenses Against Session Abuse)でも、セッションの可視化や管理に関する確認項目が示されています。
あわせて、通常と異なるセキュリティイベントが発生した場合に利用者へ通知することも有効です。ただし、重要性の低い通知を大量に送ると通知疲れにより見落としが発生するおそれがあるため、新規端末からのログインや通常と異なる地域・環境からのアクセスなど、リスクの高いイベントを中心に通知する設計が望まれます。
3.3 同時ログイン数の制御#
同一アカウントによる同時ログインをどこまで許容するかは、アプリケーション設計上の判断事項です。複数端末からの正規利用が一般的なサービスもありますが、長時間のセッション維持を許容する場合には、同時に成立するセッション数を制御することで、セッションの拡散や並行的な悪用のリスクを抑えやすくなります。
同時ログインを制限する具体的な実装としては、新規ログインを優先して既存の古いセッションを終了する方式、新規ログイン自体を拒否する方式、利用者にどのセッションを残すか選択させる方式などが考えられます。
この対策により、攻撃者が正規利用者と並行して長期間セッションを維持することは困難になります。
一方で、上限数以内での並行利用までは防げず、設計によっては、攻撃者による新規ログインによって正規利用者のセッションが強制的に終了させられるなど、妨害につながる可能性もあります。そのため、この対策は単独で用いるのではなく、3.2で述べたログイン状態の可視化や利用者への通知とあわせて実装することが望まれます。
4. 緩和策実施後も残存するリスク#
上記の緩和策を講じたとしても、長時間有効なセッションそのものが持つリスクを根本的に解消できるわけではありません。これらは不正利用の防止・検知・封じ込めをしやすくするための対策であり、セッションが有効である限り、攻撃者がそのセッションを用いて情報の閲覧や操作、攻撃の下調べなどを行える可能性は残ります。
各緩和策に対しても、以下のような残存リスクがあります。
再認証の要求(3.1)は、重要操作やリスクイベント発生時に追加の本人確認を挟むことで被害の拡大を抑止できますが、再認証の対象として定義されていない操作については保護が及びません。また、情報の閲覧や攻撃の下調べのような、再認証の対象になりにくい行為までは防げません。
ログイン状態の可視化・通知(3.2)は、利用者が不審なセッションに気づき対処するための手段を提供しますが、利用者が通知を確認し対応するまでの間の不正利用は防げません。異常に気づけるかどうか自体が利用者に委ねられるという限界もあります。
同時ログイン数の制御(3.3)についても、3.3で述べたとおり、上限数以内での並行利用や実装によっては正規利用者への妨害といったリスクが残ります。
これらの緩和策はあくまでリスク低減策として位置づけ、セクション2で述べた適切なタイムアウト設定を根本対策として継続的に見直すことが重要です。緩和策を導入した場合でも、それを恒久対策とみなすのではなく、タイムアウト値の短縮や認証方式の強化を含め、継続的に改善を検討する必要があります。