<h2>60歳からのホワイトハッカーへの道 #8</h2>


<p>

今回は「Cookie（クッキー）」と「Session（セッション）」について勉強します。

</p>


<p>

Cookieといえば、お菓子のクッキーを思い浮かべますが（笑）、

インターネットの世界では、ブラウザがWebサイトとのやり取りに使う小さなデータのことです。

</p>


<p>

普段、Webサイトにログインすると、ページを移動してもログイン状態が続きます。

考えてみれば、これは不思議なことです。

</p>


<p>

前回勉強したHTTPは、基本的に1回1回の通信が独立しています。

それなのに、なぜWebサイトは私がログインしていることを覚えているのでしょうか？

</p>


<p>

今回は、自分で作ったRailsブログ

<a href="https://www.rails-fumiblog.com/" target="_blank" rel="noopener noreferrer">

rails-fumiblog

</a>

を使って実験してみました。

</p>


<h3>1．CookieとSessionの違い</h3>


<p>

まずは、それぞれの役割を整理してみます。

</p>


<p>

<strong>Cookie</strong>は、Webサイトから受け取った情報をブラウザが保存し、

次のアクセスでサーバーに送り返すための仕組みです。

</p>


<p>

一方、<strong>Session</strong>は、複数のHTTP通信にまたがって、

ログイン状態などを維持するための仕組みです。

</p>


<p>

私のRailsブログでは、次のコマンドでセッションの保存方式を確認しました。

</p>


<pre><code>bin/rails runner 'puts Rails.application.config.session_store'</code></pre>


<p>結果は、</p>


<pre><code>ActionDispatch::Session::CookieStore</code></pre>


<p>

CookieStoreという仕組みが使われていました。

</p>


<p>

RailsのCookieStoreでは、セッション情報を暗号化・認証されたCookieとして

ブラウザ側に保存できます。

単にセッションIDだけをブラウザに保存する方式とは違うのですね。

</p>


<h3>2．curlでCookieを確認してみる</h3>


<p>

まず、ターミナルから自分のブログにアクセスします。

</p>


<pre><code>curl -I https://www.rails-fumiblog.com/users/sign_in</code></pre>


<p>

レスポンスヘッダーに、次のような情報がありました。

</p>


<pre><code>HTTP/2 200


set-cookie: _rails_fumiblog2_session=（値は非公開）;

path=/;

secure;

httponly;

samesite=lax</code></pre>


<p>

おおっ！ 本当にCookieが返ってきました。

</p>


<p>

ここで気になったのが、Secure、HttpOnly、SameSiteという設定です。

</p>


<ul>

  <li><strong>Secure：</strong>HTTPS通信でのみCookieを送信する。</li>

  <li><strong>HttpOnly：</strong>JavaScriptからCookieを読み取れないようにする。</li>

  <li><strong>SameSite=Lax：</strong>一部のクロスサイトリクエストでCookieの送信を制限する。</li>

</ul>


<p>

普段は何気なく使っているログイン機能ですが、

裏側ではこうした安全対策が働いているのですね。

</p>


<h3>3．Cookieを保存して送り返してみる</h3>


<p>

次はcurlでCookieを保存してみます。

</p>


<pre><code>curl -c cookies.txt https://www.rails-fumiblog.com/users/sign_in -o /dev/null</code></pre>


<p>

これで、受け取ったCookieをcookies.txtに保存できます。

</p>


<p>

続いて、そのCookieを使ってアクセスします。

</p>


<pre><code>curl -v -b cookies.txt https://www.rails-fumiblog.com/users/sign_in -o /dev/null</code></pre>


<p>

通信内容を確認すると、リクエストにCookieが付いていました。

</p>


<pre><code>Cookie: _rails_fumiblog2_session=（値は非公開）</code></pre>


<p>

つまり、ブラウザが普段自動で行っているCookieの送信を、

curlでも再現できたわけです。

</p>


<p>

自分でコマンドを実行してみると、理解が進みます。

</p>


<h3>4．ChromeでCookieを調べようとしたら事件発生！</h3>


<p>

次はChromeの開発者ツール（DevTools）でCookieを確認します。

</p>


<p>

ところが、なぜかCookieが表示されません。

いろいろ触っているうちに、とうとうWebサイトまで表示できなくなってしまいました。

</p>


<pre><code>ERR_INTERNET_DISCONNECTED</code></pre>


<p>

えっ？ インターネットが切れた？

</p>


<p>

慌ててMacのターミナルで通信を確認しました。

</p>


<pre><code>ping -c 3 8.8.8.8</code></pre>


<p>

結果はパケットロス0％。問題ありません。

</p>


<p>

さらに、

</p>


<pre><code>curl -I https://www.google.com</code></pre>


<p>

こちらもHTTP/2 200。正常です。

</p>


<p>

Macはインターネットにつながっているのに、Chromeだけがつながらない。

</p>


<p>

原因は、なんとDevToolsのNetwork設定でした。

</p>


<pre><code>Offline

  ↓

No throttling</code></pre>


<p>

自分でChromeをオフライン状態にしていたのです（笑）。

</p>


<p>

設定を戻したら、無事に通信が表示されました。

</p>


<p>

失敗も勉強のうちですね。

</p>


<h3>5．ログインするとCookieは変わるのか？</h3>


<p>

いよいよ今回の本題です。

</p>


<p>

ChromeのDevToolsで、自分のブログのセッションCookieを確認しました。

</p>


<pre><code>_rails_fumiblog2_session</code></pre>


<p>

まずログイン前のCookieを確認します。

その後、ブログにログインしてもう一度確認しました。

</p>


<p>

ところが、最初は「値が変わっていない！」と思ってしまいました。

</p>


<p>

よく調べてみると、確認していた場所が違っていました。

下の詳細表示を見ていたのですが、

上のCookie一覧表にあるValueを確認すると、ちゃんと変化していました。

</p>


<p>

念のため、Chromeのシークレットウィンドウでも試しました。

こちらでもログイン前後でCookieが変わることを確認できました。

</p>


<p>

つまり、Railsがログインに伴ってセッション情報を更新していたのです。

</p>


<h3>6．ログアウトするとどうなる？</h3>


<p>

最後に、ログアウトしてCookieを確認しました。

</p>


<p>

すると、今度もCookieの値が変わりました。

</p>


<p>

今回確認できた流れは次のとおりです。

</p>


<pre><code>【ログイン前】

セッションCookieが存在

       ↓

【ログイン】

RailsとDeviseがログインを処理

       ↓

セッションCookieの値が変化

       ↓

【ログイン後】

ログイン状態を維持

       ↓

【ログアウト】

セッションが更新される

       ↓

Cookieの値が再び変化</code></pre>


<p>

これで、HTTP通信そのものは前回の状態を覚えていなくても、

CookieとSessionによってログイン状態を維持できる仕組みが見えてきました。

</p>


<h3>7．ホワイトハッカーとして覚えておきたいこと</h3>


<p>

今回、一番重要だと思ったのは、

<strong>セッションCookieはログイン状態に関係する大切な情報</strong>

だということです。

</p>


<p>

もし有効なセッションCookieが第三者に盗まれれば、

条件によっては本人になりすましてアクセスされる危険があります。

</p>


<p>

だからこそ、HTTPS、Secure、HttpOnly、SameSiteなどの対策が重要なのですね。

</p>


<p>

ただし、これらを設定しただけですべての攻撃を防げるわけではありません。

</p>


<p>

また、Cookieの値をブログやSNSに公開しないことも大切です。

今回の実験でも、値そのものは非公開にしました。

</p>


<h3>8．今回のまとめ</h3>


<p>

今回の勉強では、CookieとSessionの仕組みを、

自分のRailsブログで実際に確認できました。

</p>


<p>

curlでCookieを保存し、Chromeでログイン前後の変化を調べ、

最後にはログアウトによる変化まで確認しました。

</p>


<p>

途中でChromeをオフラインにしてしまうという失敗もありましたが、

pingとcurlを使って原因を切り分ける経験にもなりました。

</p>


<p>

こうして考えると、普段使っている自分のRailsブログが、

そのままホワイトハッカーの教材になっています。

</p>


<p>

60歳からの勉強ですが、知らなかった仕組みが一つずつ分かっていくのは楽しいものです。

</p>


<p>

次回も、自分の手を動かしながら勉強を続けていきたいと思います。

</p>


<p>

人生、なかなか面白いものです（笑）。

</p>