2022/02/13 18:06
yuu-yuiken
“CookieだろうがlocalstorageだろうがどっちもXSSの前には無力”
2022/02/13 18:15
zentarou
HttpOnly属性ついていれば多少マシ程度だよね。XSSあるなら他に色々被害出る。
2022/02/13 21:27
rmanzoku
素晴らしいまとめだ。
2022/02/13 22:08
Shinwiki
ほんとこれ揺れる
2022/02/13 22:53
aukusoe
“まぁ、頑張って考えてもユーザや会社からは何の評価もされないと思いますけど。” ふええ……
2022/02/13 23:07
hasiduki
無限に続くセキュリティ道！
2022/02/14 00:10
momote368
最初の釣り針がデカすぎる
2022/02/14 00:11
onesplat
内容はともかく同僚にいたら面倒臭そう。感情が安定してなさそう
2022/02/14 00:45
sin20xx
脆弱性を埋め込まない可能性の高い技術で実現すればよいかと。そもそも設計の自由度が高い局面であればリードエンジニアの判断に従うだけで、その人の技術スタックや好き嫌いに左右されるし、自由度がないならば（ry
2022/02/14 00:48
uva
「まぁ、頑張って考えてもユーザや会社からは何の評価もされないと思いますけど」つらいよね
2022/02/14 02:40
jaguarsan
身も蓋もないこと言うと、フレームワークに含まれるか、ライブラリ化するかして今月ジョインしたメンバーが安全に扱えるならどちらでも良い
2022/02/14 04:33
taguch1
毎度議題に上がるが基本XSSやられてる時点で誤差っていうことに収束する。結局やられた時に任意のログインを無効にできればいいと思ってる。
2022/02/14 07:12
strawberryhunter
「Chatwork...期限を30分と短くしてその期限内の悪用は許容」変更の反映に最大30分かかるのを許容できるかどうかによる。結局、自前でセッション管理しているのと変わらなかったり、JWT自体が人類にはほんの少しだけ早い。
2022/02/14 07:30
pascal256
素晴らしい整理。この記事にも書かれてるけどリフレッシュトークンをどう管理するのかがずっと大事だし。
2022/02/14 07:35
kijtra
どっちで作ってもいいなら、個人的には GDPR を考えて localStorage かな。
2022/02/14 07:59
mohno
要約すると「もう格納場所でいがみ合うのはやめよう」（←たぶん違う）/「まぁ、頑張って考えてもユーザや会社からは何の評価もされないと思いますけど」
2022/02/14 08:43
kkobayashi
XSSがあってもセキュアに、という要件が矛盾しているんだけどね。デファクトスタンダードというかベストプラクティスみたいなのないのかな
2022/02/14 08:52
yoshikidz
わかりみが深すぎてやばい“最近はウェブサイト作ったら作っただけ脆弱性になるんじゃないかとヒヤヒヤしながら作ってます”
2022/02/14 09:03
ed_v3
結局リフレッシュトークンはどこに保存するんだ…ってなりそう。
2022/02/14 09:16
forest1040
“まぁ、頑張って考えてもユーザや会社からは何の評価もされないと思いますけど。” 辛辣コメント。あわあわ。
2022/02/14 09:32
sigeharucom
全画面SPAにして、ブラウザのメモリ上に保存しよう。
2022/02/14 11:26
tettekete37564
普通にハッシュ値 + Cookie で使った方が良いと思うけどね
2022/02/14 13:11
letsspeak
全部同意しかない