Cookieって何

JWTはわかったので次Cookieについて固める

まずこちら
https://zenn.dev/ak/articles/225832b7889281

あーでもそれはJWTでいう認可サーバーみたいな感じなのかな、だから保持し続ける主体はサーバーではなくクライアント(ブラウザ)っぽい、だからJWTとほぼ同じかも

Cookieとは、一言で言うと、サーバーからブラウザに送信される小さな文字列データのことです。

HTTP Cookie (ウェブ Cookie、ブラウザー Cookie) は、サーバーがユーザーのウェブブラウザーに送信する小さなデータであり、ブラウザーに保存され、その後のリクエストと共に同じサーバーへ返送されます

HTTP Cookie - MDN

これはシンプルに忘れてた、HTTPはステートレス

HTTPはステートレス

まず、覚えておかないといけないのは、HTTPがステートレスなプロトコルであるということです。ステートレスとは、「状態が無い」という意味で、以前送ったリクエストやレスポンスについては、まったく覚えていないことを指します。

ん、クライアントもサーバーも覚えてないのか...なるほど

ほーなるほど、原始的な状態だとそういう感じなのか

例えば、あるWebサイトにログインする場合を考えてみましょう。最初のリクエストでユーザー名とパスワードを送信して、ログインが成功したとしても、その次のリクエストで、サーバーはあなたが誰か忘れてしまいます。

JWTと存在意義同じっぽい気もするな、違いが気になる

これでは、毎回ログインし直さないといけないので不便ですよね。そこで、この問題を解決するためにCookieが登場します。

なるほど、とりあえずJWTでいう認可サーバーみたいな概念を一旦なくして、リソースサーバから直接クライアントがトークンを貰うみたいな感じで、そのトークンがcookieになったという感じらしい

もっと詳しく見ていく、mdn見てみるか
https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies

ふむ、とりあえず基本の説明

Cookie（ウェブ Cookie、ブラウザー Cookie とも呼ぶ）は、サーバーがユーザーのウェブブラウザーに送信する小さなデータです。ブラウザーは Cookie を保存したり、新しい Cookie を作成したり、既存の Cookie を変更したり、後でリクエストされたときに同じサーバーにそれらを送り返したりすることができます。 Cookie により、ウェブアプリケーションは限られた量のデータを格納し、状態についての情報を記憶することができます。HTTP プロトコルは既定ではステートレスだからです。

へぇ、無効なセッションID cookieだったらそのセッションIDをサーバーが勝手に消去するらしい。もう不要だからみたいなことなのかな

4. サーバーはセッション ID をチェックし、有効であれば、ユーザーに新しいページの個人設定版を送信します。無効であれば、セッション ID は削除され、ユーザーにはページの一般版が表示されます（あるいは、「アクセスが拒否されました」というメッセージが表示され、再度サインインするよう求められる場合もあります）。

なるほど、ログインだけじゃなくてUIテーマとかいろいろ記憶する必要があるのか確かに

Cookie は、主に次の 3 つの用途で使用されます。

• セッション管理: ユーザーのログイン状態、ショッピングカート、ゲームのスコア、またはその他のユーザーセッションに関するサーバーが覚えておくべきその他のもの。
• パーソナライズ: 表示言語や UI テーマのようなユーザー設定。
• トラッキング: ユーザーの行動の記録および分析。

あとトラッキングの目的もあるのか、ということはマーケティングに繋げるだろうからユーザーの利便性関係なしにサーバー側/企業側の利益のために使われる意味合いもあるという解釈ができそうだ

へぇ～なるほど、「認証を使用したサーバーとの通信」という概念が無かったのか？

ウェブの初めの頃、Cookie は汎用的なクライアント側データのストレージ用途に使用されていました。他に選択肢がなかったためです。

ほーlocalStrage, sessionStrageのことをウェブストレージAPIというらしい、今度調べよう

より新しいストレージ API 、例えば ウェブストレージ API (localStorage および sessionStorage) や IndexedDB などが現在では推奨されています。

うーんと、どういうことだ

これらはストレージを前提に設計されており、サーバーにデータを送信することはなく、Cookie をストレージとして使用する際に生じる、次のような他の欠点もありません。

• ブラウザーは一般的に、ドメインごとの Cookie の最大数（ブラウザーによって異なりますが、通常は数百）と、Cookie ごとの最大サイズ（通常は 4KB）に制限されています。ストレージ APIは 、より大量のデータを格納することができます。 Cookie はリクエストのたびに送信されるため、パフォーマンスを低下させる可能性があります（例えば、モバイルの低速データ接続の場合）。特に、多くの Cookie を設定している場合はその傾向が強くなります。

主張は以下2つという理解で良いかな？

1. Cookieをストレージとして使用すべきでない
2. Web Storage APIはストレージだが、そもそもストレージ前提として作られているのでCookieのように通信速度が遅くなるような問題は起こらない

だがなぜ2つ目が実現できるのかはまだわからない

Web Storage APIはCookieより大量のデータが格納されていそうだが、それでも低速通信になるみたいな問題は起こらないのはなぜ？

ストレージ APIは 、より大量のデータを格納することができます

"前提"という言葉が使われているから、「Web Storage APIは最初から通信が遅くならないように設計してるから大丈夫よ」ということなのかな？

へー

HTTP リクエストを受信した後、サーバーはレスポンスに 1 つまたは複数の Set-Cookie ヘッダーを送信することができ、それぞれのヘッダーが別個の Cookie を設定します。単純な Cookie は、次のように名前付きの値のペアを指定することで設定されます。

HTTP

Set-Cookie: <cookie-name>=<cookie-value>

おーChrome DevToolsのNetworkタブ覗いてみたらほんとだ、Set-Cookieのとこに_zenn_session=〇〇みたいなやつあった

これ「次の」って「2回目の」という意味ではなく「以下の」というだけの意味だ

次の HTTP レスポンスは、受信側のブラウザーに Cookie のペアを格納するように指示します。

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[ページの内容]

なるほど

ほー、案外単純だなぁ

新しいリクエストが行われると、ブラウザーは通常、HTTP ヘッダー内の Cookie で、前回格納された Cookie を現在のドメイン用にサーバーに送信します。

GET /sample_page.html HTTP/2.0
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

へぇ～～～

有効期限日または期間を指定すると、それ以降は Cookie が削除され、送信されなくなります。Cookie を作成する際に Set-Cookie ヘッダーに設定する属性に応じて、永続的 Cookie またはセッション Cookie のどちらかになります。

• 永続的 Cookie は、Expires 属性で指定された日時が過ぎると削除されます。

HTTP

Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;

• または、Max-Age 属性で指定した期間が経過した後にも削除されます。

HTTP

Set-Cookie: id=a3fWa; Max-Age=2592000

なるほど～～、パソコンの時間設定をめちゃくちゃにしてたらそれに基づいたExpiresとサーバーとの間で不整合が生じエラーに繋がるかも、ということか

メモ: Expires は Max-Age よりも長い期間の指定ができますが、Max-Age のほうがエラーの可能性が低く、両方が設定されている場合はこちらが優先されます。この理由としては、Expires で日時を設定した場合、Cookie が設定されているクライアントの日時との相対値となるためです。もしサーバーが異なった日時を指定していると、エラーが発生する可能性があります。

とりあえず"永続的"Cookie とは言うものの永続的という単語の意味は実は「永遠に続く」ではなく「永く(長く)続く」というだけなので、結果としていつかは消えるということに注意だな

次、セッションCookie

• セッション Cookie（Max-Age または Expires 属性のない Cookie）は、現在のセッションが終了すると削除されます。ブラウザーが「現在のセッション」がいつ終わるかを定義しますし、ブラウザーによっては再起動時にセッションを復元することもあります。これにより、セッション Cookie がいつまでも有効な状態になるという問題が発生する可能性があります。

なるほど、セッションが生きてる間しか機能しないcookieか

セッションと一心同体なCookie

ん、なるほど..？

メモ: ユーザー認証を行うウェブサイトでは、ユーザーが認証を行うたびに、すでに存在するセッションCookieも含めて、再生成して再送信する必要があります。この手法は、サードパーティがユーザーのセッションを再利用する「セッション固定攻撃」を防ぐのに役立ちます。

まぁ非効率感はあるけど確かに必要だろうし、Cookieの意味がなくなってしまうということでもないな別に

そのセッションがあったからこそログインができるので意義はある。そのログインが終了した後にそのセッションを新しいものに自動で変えてくれる、みたいな感じだと思う

ゾンビCookie、ネーミングセンスが最高だ
まぁでも同じものを復元しているのではなく新しいセッションとして生成しなおしてるんだろうからちょっと意味合い違くなってきそうではあるけど

Cookie が削除された後に Cookie を再作成するよう設計された技術がいくつかあります。これらは「ゾンビ Cookie」として知られています。これらの技術は、ユーザーのプライバシーと制御の原則に違反し、データプライバシー規制に違反する可能性があり、また、それらを使用するウェブサイトが法的責任を問われる可能性もあります。

ん、でもなんでプライバシー規制に違反する可能性があるという危険視がされてしまうんだろう

そのセッションが正しいものであれば認証/ログインさせてあげて、その直後にセッション再生成してその(真の)ユーザーに返すというだけだよな、、？であれば何の問題も無いしむしろさっきの「セッション固定攻撃」なるものを防ぐために必須なんだろうから、とても良いものな気がするんだが、、

まぁ一旦飛ばす

確かに銀行アカウントとかログインされたらやばいかも（さすがにパスワード入力とかもあるだろうけど）

セキュリティ

Cookie に情報を格納した場合、既定ではすべての Cookie 値がエンドユーザーに表示され、変更することができます。例えば、悪意のある人物が Cookie にアクセスしたり、変更したり、本来送信されるべきではないドメインに送信したりするなど、Cookie が悪用されることは避けなければなりません。 その潜在的な影響は、アプリケーションが動作しない、あるいは奇妙な動作をするなど、わずらわしいものから、壊滅的なものまで、さまざまな範囲に及びます。 例えば、犯罪者がセッションIDを盗み、それを他人になりすましてログインしているように見せかけるCookieを設定し、その過程で銀行口座や e コマースのアカウントを制御できる可能性があります。

Cookie を保護する方法はいくつかあり、この節で説明します。

保護する方法気になる

ほう

Cookie へのアクセスをブロック

Cookie が安全に送信され、意図しない第三者やスクリプトからアクセスされないようにするには、 Secure 属性と HttpOnly 属性の 2 つの方法があります。

HTTP

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly

なるほど～～

• Secure 属性がついた Cookie は、HTTPS プロトコル上の暗号化されたリクエストでのみサーバーに送信されます。安全でない HTTP では決して送信されないため、中間者攻撃の攻撃者が簡単にアクセスすることはできません。（URL に http: のついた）安全でないサイトは、 Secure 属性を使用して Cookie を設定することができません。ただし、Secure によって Cookie 内の機密情報へのアクセスをすべて防げると思ってはいけません。例えば、クライアントのハードディスクへアクセスすることで（また、HttpOnly 属性が設定されていない場合は JavaScript から）読み取られる可能性があります。
• HttpOnly 属性を持つ Cookie は、 JavaScript の Document.cookie API にはアクセスできません。サーバーに送信されるだけです。例えば、サーバー側のセッションを持続させる Cookie は JavaScript が利用する必要はないので、HttpOnly 属性をつけるべきです。この予防策は、クロスサイトスクリプティング（XSS）攻撃を緩和するのに役立ちます。

• Secure

中間者攻撃が難しいhttpsオンリーにする

• HttpOnly

JSでDocument.cookie API にアクセスできなくする

JWTの方が良かったりもすると

メモ: アプリケーションによっては、機密情報を直接 Cookie に格納するのではなく、サーバーが照合する不透明な識別子を使用したり、JSON Web Tokens などの代替の認証/機密性メカニズムを調べたりしたほうがいいかもしれません。

JWTと違ってCookieはログイン情報なども含んでしまう？からかもしれない
あとJWTは公開鍵/暗号化とかが導入できるのが強みなのかもしれない

次こちら
https://qiita.com/doyaaaaaken/items/02357c2ebca994160804

ジョットとCookieの違い

ヘッダに載せるのは同じか

CookieとJWTはいずれもHTTPリクエストのヘッダにそれらを載せて送信するという点では同じ

なるほど～～～

最も大きな違いはCookieがstateful・TokenがStatelessという点

cookieに関してはちゃんとDBにアクセスしてちゃんと生のユーザ情報を参照するから重いのか

• パフォーマンス
  • Tokenの場合は署名の検証処理だけですむ
  • 一方CookieにsessionIdを入れていた場合は、sessionIdを元に、session情報を取得する（RDBやNoSQL DBから）処理が必要で遅くなる

Cookieは「セッション」という大枠で捉えて良さそうだ

あーCookieはstatefulとは言えsessionIdしか持ってないっぽい。sessionIdを保持していることをstatefulと呼んでる

• Cookieはサーバ側でsession情報を持つ。CookieにはsessionIdを入れており、リクエストの都度sessionIdに紐づくサーバ側sessionデータを参照している。

確かに、「認証に成功したという情報」を持っているという表現は良いなぁ
「認証情報そのもの」ではなく「認証に成功したことあるぜ」という情報

• Tokenはクライアント側で「認証に成功した」という情報（＝Token）を持ち、リクエストの都度それを送る。

ん－と、cookieもjwtも読まれる可能性があるということで良いだろうか

• データがJWT内に保存される
  • CookieだとsessionIdだけだが、JWTだとJSONなので、デコードしてやれば読むことができる
    つまり（デコードしてやれば）フロントエンドから直接データにアクセス可能

なので「違い」とか「Tokenのメリット」ではない気がする

ほー、CookieはWebオンリーなのかな？であれば確かにマルチプラットフォーム対応するJWTのメリットは強そうだ

• モバイル対応
  • Cookieを使用しないプラットフォームだった場合もJWTは使える

なるほど

• Tokenのデータサイズ
  • sessionCookieは小さい（sessionIdが入ってるだけ）。一方JWTはそれよりはでかくなる。

やっぱCookieはsessionIdが入っているだけというのが実態かも..？解像度が上がった

たしかに_zenn_session=〇〇みたいな感じだったしなぁ

mdnにも書いてある。このcookie-nameがsessionIdだと思って良さそう

Set-Cookie: <cookie-name>=<cookie-value>

https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies#cookie_の作成、削除、更新

うーむ

• XSSでLocal StorageにアクセスされTokenが盗まれることで、Sessionハイジャックが可能になるので注意。
  • （簡単に盗めそうだけど大丈夫なんだろうか？？受動型の攻撃だし、XSSの対策はHTTPヘッダやフレームワークレベルで色々防げるから大丈夫ということか？？）

さっきのCookieの例で出てきたHttpOnlyでJS機能させなくするってやつ、JWTにも適応できるのかな？であればとりあえず大丈夫な気はする

最後こちら読む
https://zenn.dev/collabostyle/articles/8949e8db686263

cookieはセッションという大枠の1つと思っていたが違うのかな..？確認していく

なるほど

そもそもなぜクッキーやらセッションが必要なのか

そもそもなぜクッキーやセッションは必要なのでしょうか。
それはHTTPはステートレスなプロトコルだからです。

全ての始まりは「HTTPがステートレスなプロトコルだから」か

ハンバーガーショップの例えわかりやすい

これも確かに

しかしこれではECサイトのような客が何をカートに入れたか覚えていないといけないステートフルが要求されるサイトでは困ってしまいますね。

あーそっか、盗聴者しか考えてなかったけど、こういう感じで既に認証クリアした人が自分のcookieを他人のものに書き換えるという攻撃もあり得るのか、確かに

しかし問題は、クッキーの内容はユーザー側で自由に書き換えられてしまう可能性がある点です。
もしもクッキーを

userID=1001

のように編集され、実際にuserIDが1001のユーザーが存在していれば、なりすましログインされる危険があります。
このように他人のセッションに侵入する攻撃を、「セッションハイジャック」と呼びます。

ほう、やはり別物ということか？

そこでセッションを使う

クッキーにユーザーのIDなどをそのまま保存してしまうと、書き換えられたり盗聴されたりしてセッションハイジャックにつながる恐れがあるという問題がありました。
しかし「ユーザーを識別してステートフルなやり取りをしたい」ニーズは依然としてありますよね。

そこで登場するのが「セッション」です。

あーそういう感じか

セッションの仕組み

セッションはクッキーを応用した仕組みで、クッキーとまったく無関係なわけではありません。
生のユーザー情報やカート情報などを直接クッキーに保存する代わりに、サーバー側で管理したデータにひも付くセッションIDのみをクッキーに保持させる、という方法を取ります。
サーバー内ではユーザーIDやカートの中身などの機密情報を、メモリ・データベース・Redisなどに保存し、セッションIDと照合する仕組みです。

むしろ自分が想定していたcookieというのがセッションを指定するものだったので、原始的なcookieはそういう風にセッションを指定することはなく生のデータを保持していたが、それを改善するためにモダンなcookieではセッションの仕組みを導入したよ、という流れなのかも

「セッション＝cookie」という理解は改めて、「厳密にはイコールでは無いが、現代のcookieはセッションの仕組みをほぼ取り入れているのでイコールと考えても良さげ」という理解でいこう

ふと思ったけど、cookieはstatefulでjwtはstatelessなのでcookieはサーバ側でがっつりsessionIdからdbアクセスしてユーザ情報取得して、みたいなことするから通信遅くなるけどその分ユーザの情報がっつり取得できる

だけどjwtはただ秘密鍵使いつつヘッダ,ペイロードのハッシュ化&base64エンコードをして、それと署名が一致するか検証するだけであって、確かに通信速度は速くなるかもだけどユーザの情報を取得することはできないんだろうなー　という気付き

jwtは高速だけど認証情報をくれるのではなく認証済みかどうか判定するだけ　かな
つまりdataではなくbooleanが返ってくるようなイメージだと思う

なるほど、これでとりあえず「自分のセッションidを他人のものに変える」行為に対処できるようになったわけか

ユーザーがログインしているかどうかや、カートの中身などの「第三者に知られたくない情報」は、ブラウザには置かずサーバー側に保管しておきます。
ユーザーがブラウザでクッキーを書き換えようとしても、そこに書かれているのは「セッションID」だけです。
もしセッションIDが推測不能なランダム文字列なら、そう簡単には別のユーザーのセッションIDを作り出すことはできません。

あー、まぁuserIdをUUIDにするならuserIdでも良いのかもしれない。べた書きの数字がやばいということなのであれば

直接的な改ざんが難しい

クッキーに「userID=1000」のようにIDを直書きしていると書き換えられてしまうかもしれませんが、セッションIDだけなら意味がありませんね(ただのランダム文字列なので)。

たとえユーザーが勝手にクッキーのセッションIDを書き換えても、サーバー側のセッションストアと紐付かない限り正しいデータは得られません。

あーIPアドレス使う手があったか（とは言え動的IPが普通なのであんま意味無いかも？）

セッションIDの盗難リスク

もしセッションIDそのものが漏れてしまうと、結局はそのIDでサーバーを騙すことが可能になり、なりすましされる危険があります(セッションハイジャック)。

対策としては以下のものがあります。

• HTTPS（TLS）で通信を暗号化する
• Secure フラグや HttpOnly フラグを付ける
• アクセス元IPアドレスのチェックやワンタイムトークン（CSRF対策）など、追加のセキュリティ機構を取り入れる

そういえば、そもそも盗まれないようにいろいろ工夫してるからまぁ大丈夫みたいな話をよく聞くが、それならパスワードをそのままブラウザに保存してもええやないか、セッションIDを保存するみたいなことしないでええやないか、という疑問が湧いた

だってセッションID盗まれたらそれ使ってサーバーに問い合わせすれば結局個人情報取得できると思うので

あー、expiresが設定できるとかが違うか

あとcookie/sessionという仕様に乗っかるからこそHttpOnly, Secure属性とかいろいろ独自のセキュリティ対策できるようになってるのかもしれない

あとセッションIDが漏れた場合はパスワード漏れと違ってそのセッションから得られる個人情報とか特定のサービスに関する個人情報とかだけしか得られないが、パスワード漏れるといろんなサービスで試されてしまう可能性もあるのか、となった