Rails7 × MySQLの環境をdocker-composeで立ち上げる(ついでにRailsで認証とセッション管理の仕組みも作る)
やること
- Rails7 × MySQLの環境をdocker-composeで立ち上げる
- リッジポールを導入してusersテーブルを作る
- サインイン機能とログイン機能とログアウト機能と認証の仕組みを作る
- セッション管理をする
- Railsはデフォルトでセッションストレージにクッキーを採用しているので、ログアウト後にセッション情報がクッキーから消えているかを確認する。また、ログアウト前にクッキーのvalueをコピーしてログアウトするとセッションが復活するかを確認する(Redisを使っているパターンだと、Redis側でセッション情報を管理しているので、クッキーのsession_idをコピーしても、ログアウト時にRedisにあるセッション情報を消しているから、セッションは復活しない)
dockerとリッジポールは終わった。
ここまでで参考にした記事
describe テーブル名で、テーブルの構造を知ることができる
describeコマンドは普通に知らなかった
mysql> show tables
-> ;
+---------------------------+
| Tables_in_app_development |
+---------------------------+
| users |
+---------------------------+
1 row in set (0.00 sec)
mysql> describe users;
+------------+---------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------------------+------+-----+---------+----------------+
| id | bigint(20) unsigned | NO | PRI | NULL | auto_increment |
| name | varchar(191) | NO | | | |
| email | varchar(191) | NO | | | |
| updated_at | datetime(6) | NO | | NULL | |
| created_at | datetime(6) | NO | | NULL | |
+------------+---------------------+------+-----+---------+----------------+
railsの_app_sessionというクッキーはなんですか?
railsの_app_sessionクッキーは、セッション管理に使用されるクッキーだそう。
Railsの_app_sessionクッキーは、セッション管理に使用されるクッキーです。
Railsでは、セッションを管理するためにクッキーを使用します。クライアント(通常はブラウザ)に送信されるクッキーには、セッションIDが含まれています。このセッションIDは通常暗号化され、サーバーがクライアントを識別するために使用されます。
_app_sessionクッキーは、デフォルトのセッション管理に使用されます。このクッキーには暗号化されたセッションIDが含まれています。セッションIDを元に、サーバーはクライアントのセッション情報を特定し、それに基づいてユーザーの状態を管理します。
例えば、ログイン状態やカートの中の商品などの情報がセッションに保存され、それが_app_sessionクッキーを通じてサーバーに送信されます。
セッションは通常、セキュリティやプライバシーの理由から暗号化されるため、クッキーの中身を直接読むことは難しいです。
なお、セッションの設定や管理方法は、config/initializers/session_store.rbファイルやconfig/application.rbファイルでカスタマイズすることができます。
docker attachは既存のプロセスにアタッチし、そのプロセスが終了するとコンテナも終了する。一方、docker execは実行中のコンテナ内で新しいプロセスを実行し、コンテナが終了することはありません。
Railsにおけるセッション管理
Railsは_app_sessionというクッキーをログインログアウトに関わらず送ってきている。
ログインした時は、この_app_sessionの値を書き換えてSet-Cookieで送っていた。
ログイン時の_app_sessionというクッキーのvalueをコピーしてログアウトした場合、ブラウザのクッキーを消した後に、document.cookieでコピーしたvalueでクッキーを作成すると、セッションが復活してしまう。これはクッキーをセッションストレージとして利用している問題点かもしれない。
やっぱRedisが良い気がしてきた。
この攻撃ってセッションリプレイ攻撃っていうらしい
要はクライアントのクッキーを盗んで同じセッションを外部ユーザーが勝手に使うこと。
セッションリプレイとセッションハイジャックの違いがよくわからん。
クッキーをセッションストレージとして使っているなら気をつけた方が良いかも。
倫理的なハッカーは、WiresharkやHping3のようなツールの助けを借りて、セッション・リプレイ攻撃を使用することができます。ハッカーの目標は、敵に悪用される可能性のある脆弱性を修正するために、ネットワーク、データ、リソースにアクセスすることです。
セッション・リプレイ攻撃は、リプレイまたはリプレイ攻撃とも呼ばれ、悪意を持って有効なデータ送信を「再試行」または「遅延」させるネットワーク攻撃です。ハッカーはセッションを傍受し、ユーザー固有のセッションID(クッキー、URL、またはフォーム・フィールドとして保存されている)を盗むことでこれを行うことができます。ハッカーは、認証されたユーザーになりすまし、認証されたユーザーがウェブサイト上でできることすべてにフルアクセスできるようになります。
リプレイ攻撃は、サイバー犯罪者がセキュアなネットワーク通信を傍受し、それを不正に遅延させたり送信したりして、受信者を騙してハッカーの思い通りにさせることで発生します。リプレイ攻撃のさらなるリスクは、ハッカーがネットワークからメッセージをキャプチャした後、メッセージを解読するのに高度なスキルさえ必要としないことです。すべてを再送信するだけで攻撃は成功する。
この記事rails + mysqlの環境立ち上げる時に参考になる
X-のprefixで始まるHTTPヘッダー
非標準ヘッダーらしい
HTTPのヘッダーでは非標準ヘッダーにX-をつけるという慣習が長らく利用されていました。最初に導入されたのはRFC-822という電子メールのためのRFCで、この中では拡張フィールドという目的でした。
最終成果物