Slide 1

Slide 1 text

YouTube Live (2020.09.10 Thur. 21:00~)

Slide 2

Slide 2 text

話す人 現役のエンジニア二人 赤貝が好きな CTO と デザイン勉強中のエンジニア @mu_vpoe 最近は SwiftUI で macOS アプリづくりが 趣味 ムー zaru @zaru CTO, Love 赤貝, JavaScript, Firebase, Web Components. Twitter フォロー お願いします!

Slide 3

Slide 3 text

セッションと Cookie の謎

Slide 4

Slide 4 text

これセッション に保存しよう これ Cookie に 保存しよう Cookie を クリアしよう Cookie が 切れてるな〜 セッションが 切れてる〜 セッションを クリアしよう こんな事を言ってるけど…

Slide 5

Slide 5 text

セッション =Cookie? 同じなの? 違うの? そもそもの疑問

Slide 6

Slide 6 text

セッションは目的、 Cookie は手段        …だよ なるほど〜??

Slide 7

Slide 7 text

謎は全てとけた! 完 やった〜

Slide 8

Slide 8 text

セッションと Cookie とは

Slide 9

Slide 9 text

どういう事なの? セッションとは 複数のリクエストを 同一ユーザと認識する事

Slide 10

Slide 10 text

HTTP はステートレス リクエスト1 リクエスト2 こんにちは サーバーさん ブラウザー君 初めまして またきたよ 初めまして 同じブラウザでリクエスト をしても、サーバからする と、同じユーザとは認識が できない ( 状態を持たない )

Slide 11

Slide 11 text

同じユーザと認識させるための セッション リクエスト1 リクエスト2 こんにちは zaru だよ サーバーさん ブラウザー君 初めまして zaru さん またきたよ zaru さん ですね 何か大いなる力で セッションを実現している

Slide 12

Slide 12 text

で、どうやるの? セッションにおける Cookie は ブラウザとサーバの通行手形                         (のようなもの)

Slide 13

Slide 13 text

ブラウザがサーバに Cookie を渡す リクエスト1 リクエスト2 zaru と証明 する cookie あげる サーバーさん ブラウザー君 cookie もぐもぐ zaru さんですね 通ってよし! またきたよ cookie もぐもぐ zaru さんですね 通ってよし! Cookie で セッションを実現している

Slide 14

Slide 14 text

え… Cookie って 誰が作ってるの…?

Slide 15

Slide 15 text

Cookie はサーバが作って ブラウザに渡す zaru のログイン ID とパスワード入力〜 サーバーさん ブラウザー君 認証できました。 証明する Cookie を あげます これをサーバサイド Cookie と呼びます。他にブラウザで JavaScript を使っ て Cookie を作ることもできます。これをクライアントサイド Cookie と呼び ます。セッションで使われる Cookie は主にサーバサイド Cookie です

Slide 16

Slide 16 text

Cookie 4KB の壁 小ネタ

Slide 17

Slide 17 text

key=value; expires=Fri, 27-Sep-2019 09:19:40 GMT; Max-Age=3600; domain=example.com 実際のCookie のデータ データ本体 key と value を = で 組み合わせている Cookie は 4KB までしか保存できない メタ情報 有効期限や有効ドメインなど (ブラウザによって多少の差はある) これ全部で 4KB 以下にする必要がある

Slide 18

Slide 18 text

Cookie を使った セッションの 具体的な実現方法

Slide 19

Slide 19 text

Cookie を使った セッション実現方法 1

Slide 20

Slide 20 text

Cookie に全部入れちゃう 例えば、ユーザ ID や会員情報などユーザに関連するデータを Cookie に入れちゃう。そ のままだとユーザが任意に書き換え可能なので、署名付きの暗号化するのが一般的。 zaru のログイン ID とパスワード入力〜 サーバーさん ブラウザー君 認証確認できました。 証明する Cookie をあ げます Key Value UserID 1000

Slide 21

Slide 21 text

Cookie を使った セッション実現方法 2

Slide 22

Slide 22 text

Cookie にセッション ID をいれる Cookie にはサーバが発効したランダムな ID を埋め込み、それをサーバが受け取ってユー ザを特定する。Redis などの永続的なデータストアに実際のデータが入っていたりする。 zaru のログイン ID とパスワード入力〜 サーバーさん ブラウザー君 認証確認できました。 証明する Cookie をあ げます Key Value SessionID BYZhS252yA データストアさん セッション ID が BYZhS252yA は ユーザ zaru です SessionID Key Value BYZhS252yA UserID 1000

Slide 23

Slide 23 text

セッションストアは 何がいいのか問題 小ネタ

Slide 24

Slide 24 text

ブラウザ Cookie 全部入り Redis DynamoDB ファイル メモリ メリット ● サーバが保持する必 要がない ● サイズ制限がない ● 自由に変更できる ● サイズ制限がない ● 自由に変更できる ● 無限にスケールし管 理コストが小さい ● ミドルウェアが必要 ない ● 自由に変更できる ● 何も用意しなくて良 い デメリット ● サイズ制限がある ● 自由に変更できない ● 管理コストがある ● ディスク容量の制限 がある ● クライアントライブ ラリがあまりない ● リクエストが多いと ファイル数が増える ● スケールしにくい ● 再起動などで消える ● 基本開発用 比較表 よく見る Web アプリの構成だと Redis を使っているところが多そう。 おすすめは Cookie 。Cookie を使って問題になるようであれば別のを検討する。 他にも memcached や RDB など色々ある → サーバサイド側 クライアント側 ←

Slide 25

Slide 25 text

古のセッション管理 URL に埋め込む 小ネタ

Slide 26

Slide 26 text

Cookie の使えないガラケーでセッションを実現するために、URL の末尾 にセッション ID をつけていた時代。取り扱いをミスるとセッション ID が漏洩する。令和の時代では使うことはないが、取扱注意という認識は 持っておいたほうが良い。 http://example.com/?PHPSESSID=asdfk113h18blj63

Slide 27

Slide 27 text

セッションとセキュリティ

Slide 28

Slide 28 text

セッションハイジャックについて セッションで使われる何らかの ID が奪われると、なりすまし が可能。逆に、開発時にはリクエストを再現できたりするので 仕組みを理解していると便利。 サーバーさん ブラウザー君 サーバーさん 偽ブラウザー君 zaru さん ですね なんらかの方法で Cookie を盗む

Slide 29

Slide 29 text

他にもセッション固定攻撃や Cookie の HTTP/Secure などのオ プション有効性などなど、セッションとセキュリティは非常に密 接な関係にあるので、利用する際には調べて検証しましょう。 あと… XSS があると色々とやばいので、そこも大事だよ…

Slide 30

Slide 30 text

ありがとうございました! 次回は... 未定! 質問感想など呟いていただけると嬉しいです! - ハッシュタグ #mu_zaru - ツイッター情報 @mu_vpoe , @zaru チャンネル登録 Good ボタン お願いします! ムーザルちゃんねる