セッションとセキュリティ

セッションとセキュリティ外部リンク: Session fixation HTTP におけるセッション管理は、web セキュリティのコアに相当します。セッションがセキュアであることを保証するために、全てのとりうる軽減策を採用すべきです。開発者はまた、適用可能なセキュリティ対策を有効/実行すべきです。セッション管理の基礎セッションのセキュリティセッションモジュールは、セッションに保存された情報を作成したユーザーだけが見られることを保証できません。セッションに紐付けられた値によっては、セッションの機密性を守るために追加の対策が必要です。セッションに保存されているデータがどれくらい重要かを評価し、さらなる防御策を展開すべきかもしれません。通常、そうしてしまうとコストが高く付きます。たとえば、ユーザーの利便性を損なうことが挙げられます。たとえば、ユーザーを単純なソーシャルエンジニアリングから守るためには、 session.use_only_cookies を有効にする必要があります。この場合、クッキーを無条件にクライアント側でも有効にしなければなりません。さもないとセッションが動作しないからです。既存のセッションIDをサードパーティに漏らす方法は複数あります。 JavaScriptインジェクション、セッションID を URL に埋め込む方法、パケット盗聴、デバイスへの物理アクセス、などです。セッションIDが漏れてしまうと、サードパーティがその特定のIDに紐付けられた全てのリソースにアクセスできるようになってしまいます。既存のセッションIDを漏らす最初の方法は、URL でセッションIDを持ち回すやり方です。もし外部サイトやリソースへのリンクが存在したとすると、セッションIDを含むURLが、外部サイトのリファラログに保存されるかもしれません。ふたつめは、より積極的な攻撃者がネットワークトラフィックを盗聴しているかもしれません。ネットワークトラフィックが暗号化されていないと、セッションIDがネットワーク越しにプレーンテキスト内に流出してしまいます。防御策は、SSL/TLS をサーバー側で実装し、ユーザーがそれを使うように強制することです。 HSTS も、セキュリティを向上させるために使えるはずです。 HTTPS でさえも、あらゆる時に機密データを保護することはできません。たとえば、CRIME や Beast 脆弱性が、攻撃者にデータを読めるようにしてしまうかもしれません。また、多くのネットワークは HTTPS の MITMプロキシを監査の目的で採用しています。攻撃者も、そうしたプロキシをセットアップしているかもしれません。セッションアダプションを防ぐためのセッション管理 PHP のセッションマネージャーは、現状ではデフォルトでセッションアダプション攻撃が可能です。アダプション攻撃が可能なセッションマネージャーは、追加のリスクを背負うことになります。 session.use_strict_modeを有効にし、かつセッションの保存ハンドラがサポートしている場合、初期化されていないセッションIDは拒否され、新しいものが作成されます。これによって、攻撃者がユーザーに既知のセッションIDを強制的に使わせることを防止できます。攻撃者はセッションID付きのリンクをペーストしたり、そうしたリンクを含んだメールを送るかもしれません。たとえば http://example.com/page.php?PHPSESSID=123456789 のようなものです。 session.use_trans_sid が有効な場合、ユーザーは攻撃者が提供したセッションIDを使ってセッションを開始してしまいます。 session.use_strict_mode は、こうしたリスクを軽減します。ユーザー定義の保存ハンドラも、セッションIDの検証を行うことで厳格なセッションモードをサポートできます。保存ハンドラを定義した全てのユーザーは、セッションIDの検証を実装すべきです。セッションIDクッキーは、domain, path, httponly, secure, そして PHP 7.3 以降では、SameSite 属性とともに設定できます。これは、ブラウザで定義されたものが優先します。この優先される仕組みを使い、攻撃者は永久に使えるセッションIDを設定できてしまいます。 session.use_only_cookies はこの問題を解決できません。 session.use_strict_mode を使うとこのリスクを軽減できます。 session.use_strict_mode=On にすると、初期化されていないセッションIDは拒否されます。 session.use_strict_mode はアダプション可能なセッション管理機構のリスクを軽減しますが、攻撃者は自らが生成したセッションIDを、初期化済みセッションIDとして使わせることが出来てしまいます。たとえば JavaScriptインジェクション攻撃です。この攻撃はこのマニュアルで推奨する方法で軽減できます。このマニュアルに従い、開発者は session.use_strict_mode を有効にし、タイムスタンプベースのセッション管理を行い、推奨する手続きを使って session_regenerate_id を使いセッションIDの再生成を行うべきです。開発者が上記全てに従えば、攻撃者が生成したセッションIDは、結局は削除されます。有効期限が切れたセッションにアクセスされたときのために、開発者は全てのアクティブなユーザーのセッションデータを保存すべきです。この情報は後に行われる調査とも関係があります。ユーザーは全てのセッションから強制的にログアウトさせられるべきです。つまり、再認証させるべきです。こうすることで、攻撃者が盗まれたセッションを悪用することを防止できます。有効期限が切れたセッションにアクセスすることが、必ずしも攻撃であることを示しているとは限りません。不安定なネットワークや、アクティブなセッションをすぐに削除してしまったりすることが原因で、正当なユーザーが、有効期限が切れたセッションにアクセスすることがあるからです。 PHP 7.1.0 以降、session_create_id が追加されました。この関数は、セッションIDの前にユーザー定義のIDをつけることで、全てのアクティブなユーザーのセッションに効率的にアクセスできます。 session.use_strict_mode を有効にすることが重要です。有効にしないと、悪意のあるユーザーが悪意のあるセッションIDを他のユーザーに設定できてしまいます。 PHP 7.1.0 より前のバージョンのユーザーは新しいセッションIDを生成するのに CSPRNG、つまり /dev/urandom や random_bytes やハッシュ関数を使うべきです。 session_create_id には衝突を検出する機能があり、セッションの INI 設定に従ってセッションIDを生成します。 session_create_id の利用が好ましいです。セッションID の再生成 session.use_strict_mode は良い軽減策ですが、十分ではありません。開発者はセッションのセキュリティのために session_regenerate_id を同時に使うべきです。セッションIDを再生成すると、盗まれたセッションIDを使われるリスクが減らせるので、 session_regenerate_id 関数は定期的に呼び出されなければなりません。たとえば、セキュリティに敏感な内容を扱っているのなら、セッションIDを15分毎に再生成するようにしてください。セッションID が盗まれた場合でも、正当なユーザーと攻撃者のセッションは両方時間切れになります。言い換えれば、ユーザーだろうと攻撃者のアクセスだろうと、期限切れのセッションにアクセスしたとしてエラーになるのです。セッションID はユーザーの権限が上昇したときは再生成されなければなりません。たとえば認証が成功した後などです。 session_regenerate_id は、認証情報を $_SESSION に設定する前に必ずコールされなければなりません。 (session_regenerate_id はタイムスタンプなどを保存するために、現在のセッションにセッションデータを自動的に保存します) 必ず新しいセッションだけに、認証済みのフラグが含まれるようにしてください。開発者は session.gc_maxlifetime によるセッションの期限切れに依存してはいけません。攻撃者は、認証済みのセッションも含めて、期限切れを防いで悪用を続けるため、ターゲットのセッションIDに定期的にアクセスしている可能性があるからです。そのかわりに、開発者はタイムスタンプベースのセッション管理を実装しなければなりません。セッションマネージャーはタイムスタンプを透過的に管理できますが、この機能はまだ実装されていません。古いセッションデータは GC されるまで保持されなければなりません。同時に、開発者は期限切れになったセッションデータが削除されることを保証しなければなりません。たとえば、session_regenerate_id(true); と session_destroy をアクティブなセッションに対して同時に呼んでは絶対にいけません。これは矛盾したように聞こえますが、これは必須条件です。 session_regenerate_id は、デフォルトで期限切れのセッションを削除しません。期限切れの認証済みのセッションが存在するかもしれません。開発者は期限切れのセッションは、誰からも消費されないようにしなければなりません。期限切れのセッションデータへのアクセスを、タイムスタンプを使うことで禁止すべきです。アクティブなセッションを突然削除すると、望まない副作用が起きます。 Webアプリケーションへの同時接続が起きたかつ/またはネットワークが不安定な場合に、セッションが突然消える可能性があります。アクティブなセッションが突然消えてしまうと、悪意のあるアクセスの可能性を検出することができなくなります。期限切れのセッションを突然削除するのではなく、開発者は短い期限切れの時間(タイムスタンプ)を $_SESSION に設定し、セッションデータにアクセスすることを自分で禁止すべきです。開発者は session_regenerate_id を呼び出した後すぐに、古いセッションデータへのアクセスを禁止してはいけません。その後の段階で禁止しなければなりません。たとえば、有線ネットワークのような安定したネットワークは数秒後、無線LAN や携帯電話のような不安定なネットワークの場合は、2, 3分後です。ユーザーのアクセスが期限切れのセッションだった場合、アクセスを拒否するべきです。攻撃されている可能性があるすべてのユーザーから、認証済みのステータスを削除することも推奨します。 session.use_only_cookies と session_regenerate_id を適切に使うことで、攻撃者によって設定された、削除できないクッキーを伴うDOSが発生することがあります。この場合、開発者はユーザーに Cookie を削除させ、セキュリティ上の問題に晒されていることを教えることができます。攻撃者は、脆弱なWebアプリケーションやウイルスに感染したブラウザのプラグイン、物理的に侵害されたデバイスなどを経由して悪意のあるCookieを設定している可能性があります。 DOS のリスクを誤解しないでください。 session.use_strict_mode=On は一般的なセッションIDのセキュリティには必須です! 全てのサイトが session.use_strict_mode を有効にすることをお勧めします。 DOS はアカウントが攻撃されている場合にだけ発生する可能性があります。アプリケーションに存在する JavaScript インジェクションの脆弱性がもっともよくある原因です。セッションデータを削除する期限切れのセッションデータは、アクセス不能にし、削除しなければなりません。現状のセッションモジュールはこの機能をうまく扱えません。期限切れのセッションデータは、できるだけ早く削除すべきです。しかしながら、アクティブなセッションは、すぐに削除してはいけません。これらの要求を満たすためには、開発者はタイムスタンプベースのセッション管理を自分自身で実装する必要があります。期限切れのタイムスタンプを $_SESSION に設定し、管理します。期限切れのセッションデータへのアクセスは禁止します。期限切れのセッションデータへのアクセスが検出された場合、そのユーザーのセッションから認証済みのステータスを全て取り除き、強制的に再認証させることをおすすめします。期限切れのセッションデータへのアクセスは、攻撃されている可能性があります。これを実現するために、開発者はユーザーごとに全てのアクティブなセッションを追跡しなければなりません。期限切れのセッションへのアクセスは、ネットワークが不安定だったり、 Webサイトへの同時アクセスも原因で起こりえます。たとえば、サーバーは新しいセッションIDを Cookie 経由で設定しようとしたが、接続が失われたため Set-Cookie のパケットがクライアントに届かなかったりする可能性があります。ある接続で、session_regenerate_id によって新しいセッションIDが発行されたけれども、別の同時接続が、まだ新しいセッションIDを受け取っていない可能性もあります。よって、開発者は期限切れのセッションへのアクセスを後の段階で禁止しなければなりません。すなわち、タイムスタンプベースのセッション管理が必須なのです。まとめると、セッションデータは session_regenerate_id や session_destroy を使って破棄してはいけません。むしろ、セッションデータへのアクセスを制御するためにタイムスタンプを使わなければなりません。 session_gc 関数に、セッションデータストレージから、期限切れのデータを削除させましょう。 Session とロックセッションデータはレースコンディションを避けるため、デフォルトでロックされます。ロックを掛けることは複数のリクエスト間でセッションデータの一貫性を保つため、必須です。しかしながら、セッションをロックしてしまうと、攻撃者がDOS攻撃に悪用する可能性があります。セッションをロックすることによるDOS攻撃のリスクを軽減するためには、ロックを最小限にすることです。セッションデータを更新する必要がないときは、読み取り専用のセッションを使うようにします。 session_start(['read_and_close'=>1]); $_SESSION を更新した後は、session_commit を使ってできるだけ早くセッションを閉じるようにします。現状のセッションモジュールは、セッションがアクティブでない時に $_SESSION が変更されたかを検知しません。セッションがアクティブでない時に $_SESSION を変更しないことは、開発者の責任です。アクティブなセッション開発者は、ユーザーごとにアクティブなセッションを追跡し続けるべきです。そして、アクティブなセッションの数がどれくらいあるかや、どのIP(や地域) からかとか、どのくらいの期間アクティブなのか、などです。 PHP はこれらを追跡しません。開発者が行うことが想定されています。これを実装するやり方はたくさんあります。ひとつの可能な実装は、データベースをセットアップして必須のデータを追跡し、関連するあらゆる情報を保存することです。セッションデータは GC されるので、開発者はアクティブなセッションのデータベースが一貫性を保つように GC されたデータに注意を払わなければなりません。一番簡単な実装は、"ユーザーIDをセッションIDの前に付ける" ことで、必須の情報を $_SESSION に保存することです。多くのデータベースは文字列の prefix を選択するのに良いパフォーマンスを発揮します。開発者は session_regenerate_id と session_create_id をこの目的で使うこともできます。秘密のデータを prefix に絶対に使わないでください。ユーザーIDが秘密の場合、hash_hmac を使うことも検討しましょう。 session.use_strict_mode はこの場合に必須です。必ず有効にするようにしてください。そうしなければ、アクティブなセッションデータベースが侵害される可能性があります。タイムスタンプベースのセッション管理は、時間切れのセッションへのアクセスを検知するのに必須です。時間切れのセッションへのアクセスが検知された場合、そのユーザーの全てのアクティブなセッションから認証済みのフラグを削除すべきです。こうすることで、攻撃者が盗んだセッションを悪用し続けることを防げます。 Session と自動ログイン開発者は有効期間が長いセッションを、自動ログインに使ってはいけません。なぜなら、セッションが盗まれるリスクが増えるからです。自動ログイン機能は、開発者が実装すべきです。 setcookie を使い、セキュアなワンタイムハッシュを自動ログインのキーとして使います。 SHA-2 より強いセキュアなハッシュを使います。たとえば、 random_bytes や /dev/urandom で生成したランダムデータを SHA-256 またはそれより強いハッシュ関数と一緒に使います。ユーザーが認証されていなかったら、ワンタイムの自動ログインキーが有効かどうかをチェックします。もし、キーが正しければ、ユーザーを認証し、新しいセキュアなワンタイムハッシュキーを設定します。自動ログインキーを使うのは一度きりです。つまり、再利用してはいけません。常に新しいものを生成するようにします。自動ログインのキーが長期間有効な認証キーである場合、できるだけ手厚く保護すべきです。 path/httponly/secure/SameSite クッキー属性をセキュアにするために使います。つまり、自動ログインキーを必要ないのに送信しないでください。開発者は自動ログインを無効にする機能や、不要な自動ログインのキーを削除する機能を実装しなければなりません。 CSRF (Cross-Site Request Forgeries) 攻撃セッションと認証は、CSRF 攻撃を防ぐことはありません。開発者は CSRF への防御を自分で実装しなければなりません。 CSRF 攻撃を防ぐために、 output_add_rewrite_var 関数が使えます。詳細はマニュアルページを参照ください。 PHP 7.2.0 より前のバージョンでは、この関数は trans sid と同じ出力バッファとINI 設定を使っていました。よって、PHP 7.2.0 より前のバージョンで output_add_rewrite_var を使うことはおすすめしません。ほとんどの Webアプリケーションフレームワークは、CSRF から防御する機能をサポートしています。詳細は、Webアプリケーションフレームワークのマニュアルを参照ください。 PHP 7.3 以降では、セッションクッキーにSameSite 属性が設定できます。この属性も、CSRF 脆弱性を軽減できる追加の対策になります。セッションに関連する INI 設定をセキュアにするセッション関連のINI設定をセキュアにすることで、開発者はセッションのセキュリティを改善できます。重要な INI 設定であっても、推奨される設定がないものがあります。開発者にはセッションの設定を強固にする責任があります。 session.cookie_lifetime=0 0 には特別な意味があります。これは、恒久的なストレージにクッキーを保存しないようブラウザに指示します。よって、ブラウザが終了した場合、セッションIDクッキーはすぐに削除されます。開発者がこの値を0以外にすると、他のユーザーがセッションIDを使うことを許す可能性があります。このため、ほとんどのWebアプリケーションは、"0" を使うべきです。自動ログイン機能が必須の場合、開発者は自前のセキュアな自動ログイン機能を実装しなければなりません。この機能のために、有効期間が長いセッションIDを使ってはいけません。前のページの関連するセクションで、より多くの情報が見つかるかもしれません。 session.use_cookies=On session.use_only_cookies=On HTTP クッキーはいくつか問題を抱えていますが、クッキーはセッションIDを管理する手段として好ましい方法であり続けています。セッションIDの管理に、可能であればクッキーだけを使うようにしましょう。ほとんどのアプリケーションはセッションIDの管理にクッキーを使うべきです。 session.use_only_cookies=Off の場合、セッションモジュールは、たとえセッションIDクッキーが未初期化であっても、セッションIDが与えられた GET や POST によって設定されたものをセッションIDに使うようになります。 session.use_strict_mode=On セッションをセキュアにするために session.use_strict_mode を有効にすることは必須ですが、デフォルトでは無効になっています。有効にすることで、セッションモジュールが未初期化のセッションIDを使うことを防げます。別の言い方をすると、セッションモジュールは、セッションモジュールが生成した有効なセッションIDだけを受け入れるようになるということです。この設定は、ユーザーによって与えられたあらゆるセッションIDを拒否します。 Cookie の仕様によって、攻撃者はローカルにクッキーのデータベースを設定したり、 JavaScriptインジェクションの脆弱性を突くことで、削除できないセッションIDクッキーを置くことが可能です。 session.use_strict_mode によって、攻撃者が初期化したセッションIDが使われるのを防ぐことができます。攻撃者は自分のデバイスでセッションIDを初期化し、ターゲットユーザーのセッションIDを設定するかもしれません。攻撃者は悪用するセッションIDをアクティブな状態に保たなければなりません。攻撃者はこのシナリオで攻撃を実行するには追加のステップが必要です。よって、session.use_strict_mode が軽減策として役に立つのです。 session.cookie_httponly=On セッションクッキーを JavaScript からアクセスさせることを拒否します。この設定によって、JavaScriptインジェクションによってクッキーを盗むことを防げます。セッションIDをCSRFトークンとして使うことも可能ですが、推奨されません。たとえば、HTMLソースが保存され、他のユーザに送られることがあるからです。開発者は、セキュリティを向上させるため、セッションIDをWebサイトに出力すべきではありません。ほとんどのアプリケーションは、httponly 属性をセッションIDクッキーに設定しなければなりません。 CSRF トークンも、セッションIDと同じように定期的に更新すべきです。 session.cookie_secure=On セッションIDクッキーを、プロトコルがHTTPSの場合にだけアクセスすることを許可します。 website が HTTPS 経由でのみアクセス可能であるなら、この設定を有効にすべきです。 HTTPS 経由でのみアクセス可能なWebサイト向けに、HSTS も検討すべきです。 session.cookie_samesite="Lax" または session.cookie_samesite="Strict" PHP 7.3 以降では、セッションIDクッキー向けに "SameSite" 属性が設定できます。この属性は、CSRF (Cross Site Request Forgery) 攻撃を軽減する手段です。 Lax と Strict の違いは、 HTTP GETリクエストを使う別の登録可能なドメインへのリクエストに対して、クッキーへのアクセスを許可するかどうかです。 Lax を使っているクッキーは別の登録可能なドメインへのGETリクエストからアクセス可能ですが、 Strict を使っているクッキーはそうではありません。 session.gc_maxlifetime=[choose smallest possible] session.gc_maxlifetime は期限切れのセッションIDを削除する設定です。この設定に依存することは推奨しません。開発者はタイムスタンプを使って、セッションの有効期間を自前で管理すべきです。セッションGC(ガベージコレクション)は、 session_gc を使って行うのが最適です。 session_gc 関数は、タスクマネージャーを使って実行すべきです。たとえば、UNIXライクなシステムだと cron が挙げられます。 GC処理はデフォルトでは確率的に行われます。この設定は期限切れのセッションが削除されることを保証しません。開発者はこの設定に依存することはできませんが、可能な限り最小の値を指定することを推奨します。 session.gc_probability と session.gc_divisor の値を、適切な頻度で期限切れのセッションが削除されるように調整してください。自動ログイン機能が必須の場合、開発者は自前のセキュアな自動ログイン機能を実装しなければなりません。詳細な情報は前のページを参照ください。自動ログイン機能のために、有効期限が長いセッションIDを絶対に使わないでください。セッション保存ハンドラモジュールによっては、期限切れの処理を確率ベースで行うためにこの設定を使わないものもあります。たとえば memcached, memcache が挙げられます。詳細については、セッション保存ハンドラのドキュメントを参照ください。 session.use_trans_sid=Off 透過的なセッションID管理を使うことは禁止されていません。開発者は必要な場合は採用しても構いません。しかし、透過的なセッションID管理を無効にすると、セッションIDインジェクションやリークの可能性が排除できるので、一般的なセッションIDのセキュリティを改善できます。セッションIDは、ブックマークされたURLや、電子メールに埋め込まれたURLや、保存されたHTMLソースなどから漏れる可能性があります。 session.trans_sid_tags=[limited tags] (PHP 7.1.0 >=) 開発者は必要ないのにHTMLタグを書き換えるべきではありません。デフォルト値でほとんどの場合は十分です。古いPHPバージョンの場合は、 url_rewriter.tags を代わりに使ってください。 session.trans_sid_hosts=[limited hosts] (PHP 7.1.0 >=) この INI 設定は、 trans sid の書き換えを許可するホストをホワイトリスト形式で定義します。信頼できないホストを絶対に追加しないでください。セッションモジュールは、この設定が空の場合、 $_SERVER['HTTP_HOST'] だけを許可します。 session.referer_check=[originating URL] session.use_trans_sid が有効になっている場合、この設定はセッションIDインジェクションのリスクを減らします。 website が http://example.com/ の場合、 http://example.com/ を設定してください。 HTTPS ブラウザはリファラヘッダを送信しないことに注意してください。ブラウザはリファラヘッダを設定によって送信しない可能性もあります。よって、この設定は信頼できるセキュリティ対策ではありませんが、この設定を使うことは推奨します。 session.cache_limiter=nocache HTTP コンテンツを認証済みのセッションに関してはキャッシュしないようにします。コンテンツがプライベートでない場合だけ、キャッシュを許可します。そうしない場合、コンテンツが外部に流出する可能性があります。 "private" は、HTTPコンテンツがセキュリティに敏感なデータを含まない場合であれば採用しても構いません。 "private" は、共有されたクライアントによってキャッシュされた、プライベートなデータを送信する可能性があることに注意してください。 "public" は、 HTTPコンテンツがプライベートなデータを一切含んでいない場合にのみ使わなければなりません。 session.sid_length="48" (PHP 7.1.0 >=) 長いセッションIDであればあるほど、強いセッションIDになります。開発者はセッションIDの長さを32文字以上にすることを検討すべきです。 session.sid_bits_per_character="5" の場合、少なくとも 26文字以上が必須です。 session.sid_bits_per_character="6" (PHP 7.1.0 >=) セッションIDの文字に多くのbitを使うほど、セッションモジュールが生成するセッションIDは、長さが同じであっても強くなります。 session.hash_function="sha256" (PHP 7.1.0 <) より強いハッシュ関数は、より強いセッションIDを生成します。ハッシュの衝突が起こる可能性は、MD5 ハッシュアルゴリズムを使っても低いですが、開発者は SHA2 またはそれより強い sha384 や sha512 のようなハッシュアルゴリズムを使うべきです。開発者は、十分に長い entropy をハッシュ関数を使うときに必ず与えなければなりません。 session.save_path=[どこからでも読み取り可能なディレクトリにしない] この設定を /tmp (デフォルト) のようにどこからでも読み込み可能なディレクトリに設定した場合、サーバー上の他のユーザーがこのディレクトリのファイルのリストを取得することにより、セッションをハイジャックをすることが可能となります。