PHPでセッションを使用する場合の落とし穴

挨拶、著名なコミュニティ。



まず第一に、非常に有用なリソースに感謝します。 何度も面白いアイデアや実用的なヒントを見つけました。



この記事の目的は、PHPでセッションを使用する際の落とし穴を明らかにすることです。 もちろん、PHPのドキュメントと多くの例がありますが、この記事は完全なガイドではありません。 セッションを操作する際のニュアンスの一部を明らかにし、開発者を不要な時間の浪費から保護するように設計されています。







セッションを使用する最も一般的な例は、もちろんユーザー認証です。 新しいタスクの出現に合わせて一貫して開発するために、最も基本的な実装から始めましょう。



（例のスペースと時間を節約するために、美しいクラス階層、包括的なエラー処理、およびその他の正しいことを備えた本格的なテストアプリケーションをここで構築するのではなく、セッションを操作する機能のみに制限します）。

function startSession() { //     ,     TRUE // ( session.auto_start    php.ini    -   ) if ( session_id() ) return true; else return session_start(); // :   5.3.0  session_start() TRUE    . //      5.3.0,    session_id() //   session_start() } function destroySession() { if ( session_id() ) { //    ,   , setcookie(session_name(), session_id(), time()-60*60*24); //    session_unset(); session_destroy(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注：読者はPHPセッションの基本的な知識を持っていると理解されているため、ここではsession_start（）およびsession_destroy（）関数の原理については説明しません。 ログインフォームとユーザー認証の組版のタスクは、記事のトピックに関連していないため、それらも省略します。 以降の各リクエストでユーザーを識別するために、セッション変数内にユーザー識別子を保存する必要があることだけを思い出します（たとえば、useridという名前で）。これは、セッションの存続期間内のすべての後続のリクエストで使用できます。 startSession（）関数の結果の処理を実装することも必要です。 関数がFALSEを返した場合、ブラウザにログインフォームを表示します。 関数がTRUEを返し、許可ユーザーの識別子（この場合はuserid）を含むセッション変数が存在する場合、許可ユーザーのページを表示します（エラー処理の詳細については、セッション変数に関するセクションの2013-06-07の追加を参照してください）。



これまでのところ、すべてが明確です。 質問は、ユーザーの非アクティブ（セッションタイムアウト）の制御を実装し、1つのブラウザーで複数のユーザーの同時操作を可能にし、セッションを不正使用から保護する必要があるときに始まります。 これについては以下で説明します。

PHPビルトインによるユーザーの非アクティブ状態の監視

ユーザー向けのあらゆる種類のコンソールの開発者の間でよく発生する最初の質問は、ユーザー側でアクティビティがない場合のセッションの自動終了です。 PHPの組み込み機能を使用してこれを行うよりも簡単なことはありません。 （このオプションは特に信頼性が高く柔軟ではありませんが、完全性のために考慮してください）。

 function startSession() { //     ( ) $sessionLifetime = 300; if ( session_id() ) return true; //     ini_set('session.cookie_lifetime', $sessionLifetime); //      ,       // :  production-       php.ini if ( $sessionLifetime ) ini_set('session.gc_maxlifetime', $sessionLifetime); if ( session_start() ) { setcookie(session_name(), session_id(), time()+$sessionLifetime); return true; } else return false; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少し説明。 ご存じのように、PHPは、リクエストヘッダーでブラウザから送信されたCookieの名前によって、開始するセッションを決定します。 ブラウザーは、このcookieをサーバーから受け取り、session_start（）関数がそれを配置します。 Cookieがブラウザで期限切れになると、リクエストでは送信されません。つまり、PHPはどのセッションを開始する必要があるかを判断できず、新しいセッションの作成と見なします。 PHPのsession.gc_maxlifetime設定パラメーターは、ユーザーの非アクティブのタイムアウトに等しく設定され、PHPセッションの有効期間を設定し、サーバーによって制御されます。 セッションライフタイムコントロールは次のように機能します（ここでは、一時ファイルのセッションストレージの例を最も一般的であり、デフォルトでPHPオプションにインストールされていると考えています）。



PHP設定パラメーターsession.save_pathにセッションを保存するためのディレクトリとして設定されたディレクトリに新しいセッションを作成すると、sess_ <sessionid>という名前のファイルが作成されます。ここで、<sessionid>はセッション識別子です。 さらに、各リクエストで、既存のセッションの開始時に、PHPはこのファイルの変更時間を更新します。 したがって、後続の各リクエストで、PHPは、現在の時刻とセッションファイルの最終変更時刻の差により、セッションがアクティブであるか、その有効期限が既に切れているかを判断できます。 （古いセッションファイルを削除するメカニズムについては、次のセクションで詳しく説明します）。



注： session.gc_maxlifetimeパラメーターは、同じサーバー内（より正確には、同じメインPHPプロセス内）のすべてのセッションに影響することに注意してください。 実際には、これは、複数のサイトがサーバー上で実行されており、各サイトにユーザーアクティビティがないために独自のタイムアウトがある場合、サイトの1つでこのパラメーターを設定すると、他のサイトのインストールにつながることを意味します。 共有ホスティングについても同じことが言えます。 この状況を回避するために、同じサーバー内のサイトごとに個別のセッションディレクトリが使用されます。 セッションディレクトリへのパスは、php.ini設定ファイルのsession.save_pathパラメーターを使用して、またはini_set（）関数を呼び出して設定します。 この後、各サイトのセッションは別々のディレクトリに保存され、いずれかのサイトに設定されたsession.gc_maxlifetimeパラメータはそのセッションでのみ有効になります。 特に在庫のユーザーアクティビティの不足を制御するためのより柔軟なオプションがあるため、このケースを詳細に検討しません。

セッション変数を使用してユーザーの非アクティブを監視する

以前のバージョンは、そのシンプルさ（ほんの数行の追加コード）で、必要なものすべてを提供しているように思われます。 しかし、すべてのリクエストがユーザーアクティビティの結果とみなせるわけではない場合はどうでしょうか。 たとえば、タイマーがページにインストールされ、AJAX要求を定期的に実行してサーバーから更新を受信します。 このような要求はユーザーアクティビティと見なすことはできません。つまり、この場合、セッションライフタイムの自動延長は正しくありません。 ただし、PHPはsession_start（）関数を呼び出すたびにセッションファイルの変更時間を自動的に更新するため、リクエストによってセッションの有効期間が延長され、ユーザーの非アクティブタイムアウトは発生しません。 さらに、session.gc_maxlifetimeパラメーターの複雑さに関する前のセクションの最後のメモは、実装が難しいと思われるかもしれません。



この問題を解決するために、組み込みのPHPメカニズムの使用を拒否し、ユーザーが非アクティブな時間を独自に制御できる新しいセッション変数をいくつか導入します。

 function startSession($isUserActivity=true) { $sessionLifetime = 300; if ( session_id() ) return true; //        (     ) ini_set('session.cookie_lifetime', 0); if ( ! session_start() ) return false; $t = time(); if ( $sessionLifetime ) { //      , //  ,       // (  ,      lastactivity) if ( isset($_SESSION['lastactivity']) && $t-$_SESSION['lastactivity'] >= $sessionLifetime ) { //  ,      , //    ,   ,     destroySession(); return false; } else { //     , //        , //   lastactivity   , //        sessionLifetime  if ( $isUserActivity ) $_SESSION['lastactivity'] = $t; } } return true; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まとめると。 各リクエストで、最後のユーザーアクティビティの瞬間から現在の瞬間までタイムアウトに達したかどうかをチェックし、それに達した場合、セッションを破棄して機能を中断し、FALSEを返します。 タイムアウトに達せず、値TRUEのパラメーター$ isUserActivityが関数に渡される場合、最後のユーザーアクティビティの時間を更新します。 あとは、呼び出しスクリプトでリクエストがユーザーアクティビティの結果であるかどうかを判断し、そうでない場合は、パラメーター値$ isUserActivityをFALSEに設定してstartSession関数を呼び出します。

2013年6月7日に更新

sessionStart（）関数の結果の処理

コメントは、FALSEが返されてもエラーの原因を完全に理解できないという事実に注意を喚起しましたが、これは完全に真実です。 ここで詳細なエラー処理を公開しませんでした（記事のボリュームはそれほど小さくありません）。これは記事のトピックに直接関係しないためです。 しかし、コメントがあれば、それを明確にします。



ご覧のとおり、sessionStart関数は2つの場合にFALSEを返します。 内部サーバーエラー（php.iniの不適切なセッション設定など）が原因でセッションを開始できなかったか、セッションの有効期限が切れています。 最初のケースでは、サーバーに問題があることとサポートサービスへの連絡方法を示すエラーを含むページにユーザーを転送する必要があります。 2番目のケースでは、ユーザーをログインフォームに転送し、セッションに有効期限が切れたことを示す対応するメッセージを表示する必要があります。 これを行うには、エラーコードを入力し、FALSEではなく対応するコードを返す必要があります。呼び出し元のメソッドでそれを確認し、それに応じて動作します。

これで、サーバー上のセッションがまだ存在していても、ユーザーの非アクティブタイムアウトが期限切れになると、最初にアクセスしたときにセッションが破棄されます。 そして、これは、グローバルPHP設定で設定されているセッションライフタイムに関係なく発生します。



注：ブラウザーが閉じられ、セッション名のCookieが自動的に破棄された場合はどうなりますか？ 次回ブラウザを開いたときのサーバーへの要求にはセッションCookieが含まれず、サーバーはセッションを開いてユーザーの非アクティブのタイムアウトを確認できません。 私たちにとって、これは新しいセッションを作成することと同等であり、機能とセキュリティには影響しません。 しかし、公正な疑問が生じます-誰が古いセッションを破棄しますか、これまでにタイムアウト後に破棄した場合？ または、セッションディレクトリで永久にハングしますか？ PHPの古いセッションをクリアするためのガベージコレクションと呼ばれるメカニズムがあります。 サーバーへの次の要求の瞬間に開始され、セッションファイルの最後の変更の日付に基づいてすべての古いセッションをクリーニングします。 ただし、ガベージコレクションメカニズムは、サーバーへのすべての要求で開始されるわけではありません。 起動の頻度（または確率）は、session.gc_probabilityおよびsession.gc_divisor設定の2つの設定によって決まります。 最初のパラメーターを2番目のパラメーターで除算した結果は、ガベージコレクションメカニズムをトリガーする確率です。 したがって、サーバーへのすべての要求でセッションクリーニングメカニズムを起動するには、これらのパラメーターを同じ値（たとえば「1」）に設定する必要があります。 このアプローチにより、セッションディレクトリはクリーンになりますが、明らかにサーバーにとっては高すぎます。 したがって、実動システムでは、session.gc_divisorのデフォルト値は1000に設定されます。つまり、ガーベッジコレクションメカニズムは1/1000の確率で開始されます。 php.iniファイルでこれらの設定を試してみると、上記の場合、ブラウザがすべてのCookieを閉じてクリアしても、古いセッションがセッションディレクトリにしばらく残ることがあります。 しかし、これはあなたを心配しないでください、なぜなら すでに述べたように、これは私たちのメカニズムのセキュリティに決して影響しません。

2013年6月7日に更新

セッションファイルのロックによるスクリプトのフリーズの防止

コメントでは、セッションファイルのブロックによる同時実行スクリプトのハングに関する質問が提起されました（最も明るいオプション-長いポーリングとして）。



まず、この問題はサーバーの負荷やユーザー数に直接依存しないことに注意してください。 もちろん、リクエストが多いほど、スクリプトの実行は遅くなります。 しかし、これは間接的な依存関係です。 この問題は、サーバーが1人のユーザーに代わって複数のリクエストを受信した場合に、同じセッション内でのみ表示されます（たとえば、そのうちの1人はロングポーリングで、残りは通常のリクエストです）。 各リクエストは同じセッションファイルにアクセスしようとします。前のリクエストがファイルのロックを解除しなかった場合、次のリクエストはハングします。



セッションファイルのロックを最小限に抑えるために、セッション変数を使用したすべてのアクションが完了した直後にsession_write_close（）関数を呼び出してセッションを閉じることを強くお勧めします。 実際には、これは、セッション変数にすべてを保存して、スクリプトの実行中にそれらを参照しないことを意味します。 セッション変数に作業データを保存する必要がある場合は、セッションの開始時にすぐに読み取り、後で使用するためにローカル変数に保存してセッションを閉じます（session_destroyを使用してセッションを破棄するのではなく、session_write_close関数を使用してセッションを閉じることを意味します）。



この例では、セッションを開いてその有効期間と承認されたユーザーの存在を確認した直後に、アプリケーションに必要な追加のセッション変数（存在する場合）をすべて読み取って保存し、session_write_close（）を呼び出してセッションを閉じ、続行する必要があることを意味します長いポーリングでも通常のクエリでも、スクリプトの実行。

セッションを不正使用から保護する

状況を想像してください。 ユーザーの1人がブラウザCookie（セッションが保存されている）を奪い、指定された電子メールに送信するトロイの木馬をキャッチします。 攻撃者はCookieを受け取り、それを使用して許可ユーザーに代わってリクエストを偽装します。 サーバーは、許可されたユーザーからの要求であるかのように、この要求を正常に受け入れて処理します。 IPアドレスの追加検証が実装されていない場合、このような攻撃により、ユーザーアカウントのハッキングが成功し、その後の結果がすべてもたらされます。



なぜこれが可能ですか？ 明らかに、セッションの名前と識別子はセッションの全期間を通じて常に同じであり、このデータを取得すると、別のユーザーに代わって（当然、このセッションの有効期間内に）リクエストを自由に送信できます。 おそらくこれは最も一般的なタイプの攻撃ではありませんが、理論的にはすべてが実行可能であるように見えます。特に、このようなトロイの木馬はユーザーのブラウザCookieを奪う管理者権限さえ必要としないことを考えると



この種の攻撃からどのように身を守ることができますか？ 繰り返しますが、明らかに、セッション識別子の有効期間を制限し、同じセッション内で識別子を定期的に変更します。 また、セッションの名前を変更して、古いセッションを完全に削除して新しいセッションを作成し、古いセッション変数からすべてのセッション変数をコピーすることもできます。 しかし、これはアプローチの本質に影響を与えないため、簡単にするために、セッション識別子に限定しています。



セッションIDの有効期間が短いほど、攻撃者がユーザーのリクエストを偽造するためにCookieを受け取って使用する時間が短くなることは明らかです。 理想的なケースでは、各リクエストに新しい識別子を使用する必要があります。これにより、他の誰かのセッションを使用する可能性が最小限に抑えられます。 ただし、セッション識別子の再生成時間が任意に設定される一般的なケースを検討します。



（すでに考慮されているコードの部分は省略します）。

 function startSession($isUserActivity=true) { //     $idLifetime = 60; ... if ( $idLifetime ) { //      , //  ,         // (  ,      starttime) if ( isset($_SESSION['starttime']) ) { if ( $t-$_SESSION['starttime'] >= $idLifetime ) { //      //    session_regenerate_id(true); $_SESSION['starttime'] = $t; } } else { //   ,      //         $_SESSION['starttime'] = $t; } } return true; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、新しいセッションを作成するとき（ユーザーが正常にログインしたときに発生します）、starttimeセッション変数を設定します。これは、最後のセッションID生成の時刻を現在のサーバー時刻と等しい値に格納します。 次に、各リクエストで、識別子の最後の生成から十分な時間が経過したか（idLifetime）を確認し、経過した場合は新しい識別子を生成します。 したがって、識別子の設定された有効期間中に、許可されたユーザーのCookieを受け取った攻撃者がそれを使用することができなかった場合、サーバーは偽のリクエストを不正とみなし、攻撃者はログインページにリダイレクトされます。



注： session_start（）と同様に新しいcookieを送信するsession_regenerate_id（）関数を呼び出すと、新しいセッションIDがブラウザーのcookieに入ります。したがって、cookieを自分で更新する必要はありません。



セッションを可能な限り保護したい場合は、識別子の有効期間を1に設定するか、session_regenerate_id（）関数を角かっこから外し、すべてのチェックを削除するだけで十分です。これにより、各リクエストで識別子が再生成されます。 （このアプローチのパフォーマンスへの影響は確認しませんでしたが、session_regenerate_id（true）関数は本質的に4つのアクションを実行しているとしか言えません：新しい識別子の生成、セッションCookieからのヘッダーの作成、古いCookieの削除、新しいセッションファイルの作成）。



叙情的な余談：トロイの木馬が非常に賢く、攻撃者にCookieを送信しないが、Cookieを受信するとすぐに事前に準備された偽のリクエストを送信するようになった場合、上記の方法は、そのような攻撃から保護できない可能性が高い偽のリクエストを送信しても実質的に違いはありません。現時点では、セッション識別子は再生成されない可能性があります。

複数のユーザーに代わって1つのブラウザーで同時に作業する機能

最後に検討したいのは、複数のユーザーが同じブラウザーで同時に作業する可能性です。この機能は、ユーザーの同時操作をエミュレートする必要があるテスト段階で特に役立ちます。使用可能な武器庫全体を使用したり、シークレットモードでブラウザーの複数のインスタンスを開いたりするのではなく、お気に入りのブラウザーで実行することをお勧めします。



前の例では、セッション名を明示的に指定しなかったため、デフォルトで設定された名前（PHPSESSID）を使用しました。これは、これまでに作成したすべてのセッションが、PHPSESSIDという名前でブラウザーにCookieを送信したことを意味します。明らかに、Cookie名が常に同じ場合、同じブラウザー内で同じ名前の2つのセッションを整理する方法はありません。ただし、ユーザーごとに独自のセッション名を使用すると、問題は解決します。やってみましょう。

 function startSession($isUserActivity=true, $prefix=null) { ... if ( session_id() ) return true; //      , //    ,   , //        (, MYPROJECT) session_name('MYPROJECT'.($prefix ? '_'.$prefix : '')); ini_set('session.cookie_lifetime', 0); if ( ! session_start() ) return false; ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、呼び出しスクリプトが各ユーザーのstartSession（）関数に一意のプレフィックスを渡すことを確認する必要があります。これは、たとえば、各リクエストのGET / POSTパラメータにプレフィックスを渡すか、追加のCookieを使用して行うことができます。

おわりに

結論として、上記で説明したすべてのタスクを含む、PHPセッションを操作するための関数の完全な最終コードを提供します。

 function startSession($isUserActivity=true, $prefix=null) { $sessionLifetime = 300; $idLifetime = 60; if ( session_id() ) return true; session_name('MYPROJECT'.($prefix ? '_'.$prefix : '')); ini_set('session.cookie_lifetime', 0); if ( ! session_start() ) return false; $t = time(); if ( $sessionLifetime ) { if ( isset($_SESSION['lastactivity']) && $t-$_SESSION['lastactivity'] >= $sessionLifetime ) { destroySession(); return false; } else { if ( $isUserActivity ) $_SESSION['lastactivity'] = $t; } } if ( $idLifetime ) { if ( isset($_SESSION['starttime']) ) { if ( $t-$_SESSION['starttime'] >= $idLifetime ) { session_regenerate_id(true); $_SESSION['starttime'] = $t; } } else { $_SESSION['starttime'] = $t; } } return true; } function destroySession() { if ( session_id() ) { session_unset(); setcookie(session_name(), session_id(), time()-60*60*24); session_destroy(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この記事が、セッションのメカニズムを実際に詳しく調べたことのない人のために少し時間を節約し、PHPに慣れ始めたばかりの人にこのメカニズムの十分な理解を与えることを願っています。