セッション固定の脆弱性について
私が読んだもの
セッションの修正に関する次のリソースを読んでいますが、この種の脆弱性のいくつかの側面を理解するのはまだ困難です。
セッションIDがサーバーによって生成され、GETおよびPOSTリクエストを介して渡されずに、Cookieから保存およびアクセスされると仮定します。上記のリンク＃1のRailsガイド）は、次のような攻撃について説明しています（ソースから要約すると、私を強調しています）。
攻撃者は有効なセッションIDを作成します。攻撃者は、セッションを修正するWebアプリケーションのログインページをロードし、応答からCookieのセッションIDを取得します（画像の1と2を参照）。
彼らはおそらくセッションを維持します。たとえば20分ごとにセッションが期限切れになると、攻撃の時間枠が大幅に短縮されます。したがって、セッションを存続させるために、時々Webアプリケーションにアクセスします。
これで、攻撃者はユーザーのブラウザーにこのセッションIDを使用するように強制します（画像の番号3を参照）。 （同じOriginポリシーのため）別のドメインのCookieを変更できない場合があるため、攻撃者はターゲットのWebアプリケーションのドメインからJavaScriptを実行する必要があります。
攻撃者は、JavaScriptコードを使用して、被害者を感染したページに誘導します。ページを表示することにより、被害者のブラウザはセッションIDをトラップセッションIDに変更します。
新しいトラップセッションは使用されないため、Webアプリケーションはユーザーに認証を要求します。
これ以降、被害者と攻撃者は同じセッションでWebアプリケーションを併用します。セッションは有効になり、被害者は攻撃に気づきませんでした。
わからないこと
さて、ここが分からないところです。この攻撃に対する効果的な対策は、被害者のユーザーが正当なサイトにログインしたときに新しいセッションIDを発行することであるという事実は別として、理由正当なサーバーは、「有効な」セッションIDをすでに持っているにもかかわらず、被害者ユーザーにとにかくログインを要求しますか？
結局のところ、攻撃者は（Railsセキュリティガイドで引用されたセキュリティガイドのステップ2で指摘されているように）固定セッションIDの有効性を事前に維持しているので、サーバーは単にセッションIDを受け入れ、被害者ユーザーを攻撃者としてWebサイトにログインします？なぜログイン認証情報であるかもう一度必要ですか？
この質問は、Ruby on Railsに固有のものではありません。フレームワークと言語でのユーザーセッションの実装に適用されます。
攻撃者は資格情報を使用してサイトにログインすることはなく、ページにアクセスしてセッションIDを取得するだけなので、被害者に有効なセッションIDを渡しても、認証されたセッションは渡されません。被害者がサイトにログインすると、セッションが認証され、攻撃者は被害者としてアクセスできるようになります。