セッションIDの固定化を防ぐ

セッション固定攻撃は、たった1行のコードで防止できます。

最も効果的な対応策は、ログイン成功後に古いセッションを無効にし、新しいセッションIDを発行することです。これなら、攻撃者が固定セッションIDを悪用する余地はありません。この対応策は、セッションハイジャックにも有効です。Railsでは以下の方法で新しいセッションを作成できます。

reset_session

ユーザー管理用にDeviseなどの有名なgemを導入していれば、ログイン・ログアウト時にセッションが自動的に切れるようになります。セッションを手動で管理する場合は、ログインした後（セッションが作成された後）にセッションを失効させること。上のメソッドを実行するとセッションにあるすべての値が削除されるので、それらの値を新しいセッションに移し替える必要があります。

その他の対応策として、セッションにユーザー固有のプロパティを保存しておき、ユーザーからリクエストを受けるたびに照合して、マッチしない場合はアクセスを拒否するという方法もあります。ユーザー固有のプロパティとして利用可能な情報には、リモートIPアドレスや user agent（webブラウザの名前）がありますが、後者はユーザー固有ではありません。IPアドレスを保存して対応する場合、インターネットサービスプロバイダ（ISP）や大企業からのアクセスはプロキシ越しに行われていることが多いので注意が必要です。IPアドレスはセッションの途中で変わる可能性があるため、IPアドレスをユーザー固有の情報として使おうとすると、ユーザーがWebアプリケーションにアクセスできなくなったり、ユーザーの利用に制限が加わる可能性があります。

どんなメソッドなのか？

def reset_session
 session.destroy
 reset_csrf_token
end

def reset_csrf_token
 controller_instance.reset_csrf_token(self) if controller_instance.respond_to?(:reset_csrf_token)
end

   def controller_instance # :nodoc:
     get_header("action_controller.instance")
   end

     # Get a request specific value for `name`.
     def get_header(name)
       @env[name]
     end

"action_controller.instance"の値を返してくれる

検索しても出てこなかった。調べられなかった。
とりあえず関数の名前だけで推測する

CSRFトークンの概要

これに対抗するための一つの方法がCSRFトークンです。CSRFトークンは、ウェブアプリケーションがユーザーのセッションごとに生成し、そのセッション中のすべてのフォームとAJAXリクエストに埋め込むランダムな文字列です。これにより、ウェブアプリケーションは、リクエストが本当にユーザー自身からのものであることを確認できます。

CSRFトークンは、ユーザーが送信するすべてのリクエストに含まれ、サーバーはそのトークンを検証します。トークンが一致しない場合、リクエストは拒否されます。これにより、攻撃者がユーザーのセッションを乗っ取ることを防ぐことができます。

これはどこのファイルの書くのか？

コントローラファイルに書くと考えている。

リセットをする前に情報を新たに移し替える必要がある

    session_user_id = session[:user_id]
    reset_session
    session[:user_id] = session_user_id

格納された情報を変数に代入、リセット、セッションに代入し直した。
これでいいのだろうか？

セッションにユーザー固有のプロパティを保存はセッションに印をつけ照合ことだと考える