セッション-常に必要ですか？

セッションを使用してユーザーを認証するというトピックをもう一度取り上げたいと思います。 記事の中で与えられた方法に対する批判を、あなたの経験の高さから聞きたいと思います。







PHPでのセッションのすべての思慮深さと優れた実装にもかかわらず、ほとんどの開発者は遅かれ早かれ標準機能を拡張/変更する必要に直面します。 対処すべき重要なポイントは次のとおりです。

1. セッション固定。 セッションの盗難から保護するために、sessidは次の情報を特徴としています。
   
   ユーザー。 通常、IPまたはUserAgent、またはすべて一緒です。
   
   
   
   あなたのsession_set_save_handler。 セッション変数をファイルシステムに保存するのは最適なソリューションではないため、
   
   遅かれ早かれ、セッションをmemcached、ベース、または他の場所に転送することを検討する必要があります。
   
   
   
   session.use_trans_sid =0。PHPに組み込まれているurl_rewriterメカニズムは非常に強力で便利なものですが、
   
   セッションでそれを使用すると、一連の不快な瞬間があります。 必死の検索エンジン、いリンク、
   
   偽名で入力、完全に無関係なサイトのログにsessidを「ライトアップ」（HTTP_REFERER経由など）
   
   したがって、この機能は通常無効になっており、sessidの送信にはCookieのみが使用されます。
   
   
   
   
   
   最後のポイントについて詳しく説明したいと思います。 事実、ほとんどの大規模なサイトは
   
   （google、ozon、livejournal、paypal ..）Cookieを介してのみ機能します。 とても奇妙に思えた
   
   Cookieを持たない人々がインターネット上で非常にまれであり、無視される可能性は低いためです。
   
   
   
   Liveinternetの統計によると、Cookieが無効になっている人の数は約4％です。
   
   少なからず。 少なくともこのような巨人が観客のこの部分を意識的に遮断する可能性は低い
   
   非常に良い理由がなければなりませんでした。 そして、彼らは見つかりました。
   
   
   
   これらの4％には、永続的なCookieを持っていない人が含まれていることがわかります
   
   （ハードセットライフタイムを使用）、セッションセッションは機能します-ライフタイム= 0 また、セッションCookieはほとんどすべてのユーザーに有効です。
   
   セキュリティ設定やlynxで「Cookieを無効にする」設定をしている人でも。 :)
   
   
   
   とにかく、100％の保証が与えられないことは明らかです。 たとえば、Cookieがファイアウォールを切断する可能性があります（ただし、これも不明です）
   
   lifetime = 0でカットします）。 ユーザーは、Cookieのサポートなしで自作のブラウザを使用できます。
   
   （例：真珠のクローラー）。 しかし、あなたは他に何を知らない...
   
   
   
   しかし、私自身の経験から判断すると（そして「上級の同志」の経験は間接的にこれを確認します）、私は実際にはそれが可能であると言います
   
   ユーザーがセッションCookieを持っていることを期待しても安全です。 また、この論文を支持して
   
   PHPのデフォルトでは、session.use_only_cookiesパラメーターは1に設定されています。 Cookieを持たないユーザーの場合、セッションは機能しません。
   
   
   
   また、通常はセッションが使用されるほとんどの場所でCookieのサポートに頼ることができるため、実際にはCookieを介して物事をより簡単で便利にすることができ、同時にすべてのケースで機能します。
   
   セッションとして。 なぜ私は簡単に言っているのですか？ Cookieがスローされたため、忘れてしまったため、手動で処方する必要はありません。
   
   ヘッダー（場所：..）、Ajaxを使用する際に覚えておく必要はありません。
   
   このリクエストがスクリプト、静的html、画像、またはcssのどれを参照しているか。 セッションは次の場合にのみ忘れられます。
   
   同じCookieを介して機能する場合、そして常にそうとは限りません。 :)
   
   
   
   ここで、独自のsession_set_save_handlerについて少し説明します。 もちろん、すべてはどのデータとどのくらいの時間に依存します
   
   保存する必要があります。 もちろん、一般的な場合は、データベースまたはファイルシステムを使用する必要があります。 セッションの寿命が短い場合、
   
   また、セッション内のデータ自体は簡単に回復でき、メモリ（またはmemcached）も機能します。 また、セッションが
   
   ユーザーの認証については、原則として、サーバー側に何かを保存することが一般的に必要かどうかを検討する価値があります。
   
   実際、Cookieを使用する場合、save_handlerを完全に破棄し、クライアントからのすべてのデータを保存できます。
   
   
   
   繰り返しになりますが、phpbb、wordpress、gmailなどによって残されたCookieの大まかな研究は、このアプローチが非常に一般的であることを示しました
   
   使用され、生命に対する権利があります。 覚えておくべき唯一のことは、クッキーは簡単に偽造できるということです。
   
   したがって、盲目的にそれらを信頼することは不可能ではありません。
   
   
   
   そして、ここでポイント1-セッション固定化に進みます。 標準のセッションメカニズムと同様に、
   
   また、送信の可能性を排除するために、ユーザーを識別する情報にCookieをバインドする必要があります
   
   彼女のもう一つ。 さらに、ユーザーによる変更の可能性からCookieを保護する必要があります。
   
   
   
   セッションと同様に、サーバーに保存してから調整することでこれを行うことができます
   
   必要な情報（同じIPとUserAgent）。
   
   しかし、サーバーには何も保存しないことにしました。 サーバーのメモリを使用せずにこれを実行できるかどうかを見てみましょう。
   
   
   
   承認の一般的なケースを検討してください。正しいユーザー名とパスワードを入力すると、Cookieにユーザーが保存されます
   
   その一意の識別子（ID）、およびサーバーにアクセスするたびに、この識別子によってユーザーを識別します
   
   ログインを検討してください。 識別子がない場合、または時間が経過した場合、ユーザーにユーザー名とパスワードを再度要求します。
   
   
   
   ここでの欠点は何ですか：
   
   
   1. ユーザーはCookie内のIDを簡単に変更でき、別のユーザーとして認識されます。
      
      
      
      ユーザーは、別のユーザーからCookieを盗み、偽装することができます。
      
      
      
      時間が経過したかどうかを判断する方法は明確ではありません。 サーバーにタイムアウトを保存しないため、次の場合はわかりません
      
      ユーザーが昨日私たちのところに来た、または彼はすでに2か月間同じCookieを持っている。 彼がいつログインしたか覚えていない
      
      特にこのコンピューターから。
      
      
      
      
      
      ユーザーがCookieのデータを変更できないようにするために、デジタル署名を使用できます。 たとえば、md5
      
      秘密の言葉とユーザーIDから。 または、このユーザーのパスワードから。 または、パスワードハッシュから、パスワード自体が
      
      データベースに保存しないでください。 要するに、ユーザーは自分自身についてのみ知っているが、他の人については知らないような情報が必要です。
      
      自分を偽装したいユーザー。 またはまったく知りません（秘密の言葉）。
      
      したがって、設定するCookieは次のようになります。
      
      

         $ cookie = $ userid。  「|」  。  md5（$ユーザーID。「秘密の言葉」）;
      

      
      
      
      
      ユーザーが別のユーザーのCookieを送信できないようにするために、同じデジタル署名でIPを使用し、
      
      UserAgent。
      
      

         $ cookie = $ userid。  「|」  。  md5（$ユーザーID。「秘密の言葉」。   
              $ _SERVER ['REMOTE_ADDR']）
      

      
      
      Cookieを受信すると、このCookieが送られてきたUserAgentとIPを使用して署名を検証します。
      
      署名が現在の誤った値を使用した場合-署名は正しくなくなり、Cookieは受け入れられません。
      
      
      
      そして最後に、行動の時。 最も簡単な方法は、ハンマーを使用することです。ユーザーが正しいCookieから正しいCookieを送信する間、
      
      IPとUserAgent-開始します。 ただし、セッションの継続時間を強制的に制限したい場合は、次を追加できます。
      
      Cookie自体の期限。 そしてまた署名する。
      
      
      
      

         $ cookie = $ userid。  「|」  。  $時間。  「|」  。  md5（
      	 $ユーザーID。  $時間。  「秘密の言葉」。 
      	 $ _SERVER ['REMOTE_ADDR']。  $ _SERVER ['HTTP_USER_AGENT']
         ）
      

      
      
      
      
      最終的に私たちが持っているもの：サイトに対してユーザーを認証し、最小限の負荷を作成するための完全に信頼できるメカニズム
      
      サーバーに。
      
      
      
      持っていないもの：多くのセッションデータを保存することはできません。 Cookieのサイズには制限があり、md5は長い行を食べます
      
      プロセッサ時間、そしてユーザーが毎回このゴミをすべてやり取りすることは価値がありません。
      
      最大長はおそらくgmailのようにする価値があります-約120バイト。 セッション中にそこに何を保存できるか
      
      「わかりません。」 いずれにせよ、多くの変数を保存する必要がある場合、私見ではまだ標準を使用する必要があります
      
      一般的なケース向けに設計されたPHPセッション。
      
      パフォーマンス。
      
      
      
      また、現在開いているセッションの数もわかりません。 無制限に開くことができます。
      
      原則として、そのような記録を保持することを妨げるものは何もありませんが、私たち自身がサーバーをオフロードしたかったのです...
      
      
      
      標準セッションを使用するよりも優れていますが、save_handlerとsession_fixationを使用しますか？ ここではすべてが一目瞭然で発生し、どこからでも介入できるという事実。 コードのシンプルさ。 まあ、スピード-汎用性と引き換えに。