Session管理
具体的な実装のことを指すわけではない
「管理」なのでそらそうmrsekut.icon
Session管理には大きく分けて2つの方法がある
ただのIDをclient/server間でやりとりするもの
これがいわゆるSessionID
server側で、Session IDとuserの情報を結びつけて保存しておく必要がある
「Session管理」と言うと普通こっちを指す気がする
statefulになる
meta dataを含んだtokenをclient/server間でやりとりするもの
userIdなどを含んだtokenをやりとりする
JWTを使うことが多そう
clientから送られてきたtokenからuserIdを取り出して使える
そのため、server側で管理する必要がない
statelessになる
何ができればSessionを管理できるか
一意のclientを特定する情報をbackendに送れば良い
client上で一意のidか何かを生成し、毎度のrequestにそれを紐付ける
backendでは、そのidと管理したいデータを紐付けて、どこかに保存しておく
server上のファイルでも良いし、DBでも良い
保存できれば何でも良い
そうすれば、statelessなHTTP通信の上であっても、
userはloginし続けられるし、
guest状態でもカートの中身を保存し続けられる
つまり、以下の2つがあればSessionを管理できる
clientからrequestに一意のidを乗せる仕組み
serverでそのidを管理する仕組み
何を使ってSession管理をするか
clientからrequestに一意のidを乗せる仕組みの例
SessionStorage
query paramsにidを付与する
serverでそのidを管理する仕組み
server上のファイル
server上のメモリ
DB
ただ、どれを選択するかでセキュリティリスクが大きく変わる
query paramsにidを付与するなどは、明らかに脆弱であると言える
よくある組み合わせは、
Cookie & server上のファイル
sessionで何を管理したいのか？にもよる
ログイン状態を管理したいのであれば、SessionStorageは向いていない
タブが消えるとログアウトされるとことになる
Session IDとそれ以外で話が大きく異なるので、分けたほうが良いかも
後者は単純
主に前者の話になる
この3つで話を分けるべきな気がする
Session ID
JWT
他の機密情報
password
クレカの番号
APIキー
その他、個人情報
etc.
Cookieに関してのSessionIDと他の機密情報の取り扱いについてはなんとなく見えてきたmrsekut.icon
jwtについてはまだ見えていない
どこに保存するか
機密情報をどこに保存するのが安全か？という話
候補
Local Storage
全くセキュアでない
JSが容易にアクセスできる
悪意のあるthrid party libraryが含まれている
XSSでJSがinjectされる
Session Storage
Local Storageとだいたい同じ
Cookie
optionを正しくつけていればそこそこ安全？
CSRFの防止になる
Cookieを暗号化された経路のみを通る
XSSされれば無力
XSSでreq投げるコードを含めておけば、browserが勝手にCookie載せてくれる
string以外も保存できる
セキュアではない
XSSがないならLocalStorageでも、Cookieでも安全
LocalStorageの方は、保存する機密情報の種類に依る
クレカとかパスワードとかは良くない
特にSession Idの場合は、安全、といえる
これはSession IDの用途が特殊だから
Q1．機密情報をlocalstorageに入れるべきではないのでは？徳丸本でもそう言ってた
A1．はい。見られて困るものは入れてはいけないですね
Q2．じゃあセッション情報（セッションIDとかセッションとしてのJWT）を入れるべきではないのでは？
A2．いいえ。XSSが無いなら、見られても無意味ですし、改ざんされても無意味なので入れてもいいと思いますよ。
なるほどmrsekut.icon
(XSSがなければ)
SameSiteからreqを送る手段がないので
XSSがあるならLocalStorageでも、Cookieでも危険
こんな感じだろうか
Cookieの中の機密情報はちゃんとしていれば漏れはしない
XSSなどがあってもJSから読み取られることはない
対して、WebStorgageはXSSなどがあれば、容易にJSから読み取れる
ただし、Cookie内のSession IDに関しては、Cookieから取り出さなくても攻撃できる
Session IDをどこに保存するか？のような話で以下を混同しないように気をつける
そのstorageの内容が第三者に見られるかどうか
web storageは見られる
cookieは見られない
session idを使って行う本来の目的を達成できるかどうか
xssがあればweb storage/cookieどちらに入っていても攻撃可能
Access tokenの有効期限を30minにする
流出してから30minの間は悪用されることを妥協する
従来の方法だと、そもそも流出に気付け無い
だから、流出に気付いてから無効にしても手遅れ
読んだ
長い
localStorageは危険、Cookieを使えという感じ
Cookieなら何でも安全という風に読めてしまう
良い
逆張り
CookieよりWebStorageの方が安全という主張
良い
私が思うに、現在の有能な攻撃者は カスタムCSRFペイロード を用いてXSSをエクスプロイトするか、 BeEFフック を利用するでしょう ref ↓client/serverの話が混ざっていいるmrsekut.icon
JWTなどをlocalStorageに保存するのはあまり安全ではない
server上の、DB・メモリ・JWTの比較
cleint上の、cookie・localstrageの比較
dbでsession管理
sessionの特性を考慮する必要がある
セキュリティ的にはAmplifyよりもAuth0のほうがいい
↓全体的に間違っている気がする
根本の理解がおかしい
何も知らない状態でこれを読んだから理解がバグった感じがあるmrsekut.icon
いいねが多いので翻弄された
利用例
Login情報
https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F62264%2F5f13c0d7-335c-8530-1351-84f89985f501.png?ixlib=rb-1.2.2&auto=format&gif-q=60&q=75&w=1400&fit=max&s=0f229973f33b33a395980851e867faf0
これでlocalにpassを保存しなくて済むのね
session idが漏洩したら誰でもログインできる
任意のリクエスト時に全session idも添付するの？
ブラウザを閉じて開き直してもloginし続けてるのはなんで？
有効期限
あるWebサイトにアクセスして、そのサイトから出て行くかブラウザを閉じるまでが1セッションとなる。1セッションで1ページしか閲覧しない場合もあれば、1セッションで何ページも見る場合もある。
ただし、Webページを開いたままにするなど、ページ閲覧とページ閲覧の間にある程度の時間が経過した場合は新たなセッションとしてカウントされる。通常、ページ閲覧とページ閲覧の間が30分以上空くと、新たなセッションとしてカウントされることが多い。
削除したい
セッションが不要になった場合は、session_unsetファンクションを使ってセッションの内容を全て削除する。