Cookieってなんぞや。属性とは？

# 抽象的な説明より、実際に見た方が早い。
結論から言うと、Cookieとはサーバからプレゼントされた秘密のコードを保存したエクセル表のようなファイル。
ただのファイルなのです。それが以下。
Path："C:\Users\User-Name\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies"
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2919278/34e680db-ab27-80a2-7f3b-5a127fb75c9e.png)


メモ帳で開く。QiitaもCookieを採用しているので当然ヒットしているが、文字化けする。
これはデータベース方式で保存されているため。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2919278/43d66d82-f082-2d92-032d-9f090e3e8900.png)


全く同じファイルをデータベースを開く専用のアプリで開くと、エクセルのような表形式で確認できる。
隠していますが右にセッションIDなどがあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2919278/487ebaba-1ba0-aa91-9cb7-c561616460a4.png)

# イメージがついた所で、Cookie利用の流れ
1."qiita.com"にブラウザ（Chrome、Edge等）がアクセス。「Cookieを保存するか」に「はい」を選択
2.返答でサーバからセッションIDなどが送信される。
3.ブラウザは、そのセッションIDなどの情報を先ほどのファイルの表に保存しておく。
4.後日、"qiita.com"にアクセスする際、Cookieを先に確認し、表に"qiita.com"があれば、そこに保存されているセッションID等を使って自動でログイン等したりする。

これだけです。

# 属性ってなに？
資格試験を勉強していると"Secure属性"や"samesite属性"などの単語が出てくる。
結論からいうと、これはCookieの属性だ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2919278/9f737936-bc02-488f-87f3-276e7070ebf7.png)
https://www.sc-siken.com/kakomon/02_aki/am2_12.html
Cookieの端をみると、属性名がある。
下図を見ると、"SSID"というCookieには"HttpOnly"にチェックが入っており、"_ga"という謎のCookieにはチェックが入っていない。
これは、SSIDはHttpOnky属性があるが、_gaにはないといえる。
属性とは、そのCookieがどんな性質を持っているかが設定されているというわけ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2919278/b110086a-2059-4fde-88ca-fb1eaf2edab2.png)

HttpOnly属性であれば、Httpからのリクエストにのみ、そのCookeiの値を返すという意味です。
つまりJavascriptから「おらCookie見せろ！」とリクエストしても見せてくれません。

ってことで雑ですがJavascriptで「おらCookie見せろ！」というコードを書いて実行してみました。
（"alert(document.cookie);"とすればサイト内で利用しているCookieをポップアップで全部表示できます。）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2919278/007d678a-8a07-4edc-a7b2-95e301c381f5.png)
実行すると、"_ga"という謎のCookieをはじめとした、多くの"HttpOnry"属性のないCookieがドバっと表示されました。
しかしいくら探してもSSIDなどの機密性の高い、HttpOnly属性が設定されたCookieはありませんでした！
しかしもしセッションIDのCookieにHttpOnly属性がなかったらと考えると…怖いですね。

「いやいや、ポップアップで自分のPCに自分のCookieが表示されただけでなにが怖いの？」とお思いかもしれませんが、実はこれ、ポップアップの内容を全然違うサイトに出力させることもできるのです。これは怖いですよね。

これはXSSのセッションハイジャックと呼ばれています。

## samesite
3種類の設定ができます。
Strict：外部にはCookieを絶対にどこにも送らない。セッションIDも連携できないので、遷移するとログインが切れる
（ストイックという意味の単語とはまた別らしいが、厳格＝どこにもCookieを提供しないと覚えやすい）
Lax：GET通信の場合のみ、Cookieを連携できる。
（リラックスと語源は同じらしい。Strictよりはゆるいけど、GETのみ。GETのヘッダーに乗るという話で、URLにそのまま記載されるわけではない。）
None：Cookie連携し放題。CSRFを防げない？（ちょっとあやふや）


# さらに理解を深めようのコーナー

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2919278/c1c95d03-8d33-2ee1-fd1e-4e38301d8ea1.png)

上記の図から分かるように、Cookieはドメイン（図にあるaccounts.google.comや、.chatgpt.com等）で別けて保存されています。
つまり、"accounts.google.com"のセッションIDは".chatgpt.com"では適用されません。
ドメインが異なると、セッションIDも使いまわせず別になるということですね。当たり前か。

また、Cookieはブラウザ毎に保存場所が異なります。
Chromeは、『C:\Users\User-Name\AppData\Local\Google\Chrome\～』
  Edgeは、『C:\Users\User-Name\AppData\Local\Microsoft\Edge\』

なので、Chromeで自動ログインできても、EdgeのCookieファイルには保存されていない場合、Edgeからは自動ログインできません。

まとめるとCookeの特徴は、
・ドメインが異なると、セッションIDは使いまわせない
・ブラウザが異なると、Cookieファイルは別のためセッションIDは使いまわせない

となります。

ドメインの件については当たり前のように感じますよね。だってGmailのセッションIDで、Qiitaにアクセスされても困りますし。
しかしこれはSSO（シングルサインオン）を利用する際、大きな障害となります。
この話はまた他の機会に