CSRF 対策はいまだに Token が必須なのか?

CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの？みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そこを絞る。 今回は Passive ではなく Active に対策していく場合を考えるので、前提をこうする。 SameSite=l

[password1234]

CSRFはユーザーが能動的に「する」ものではなく、意図せず「させられてしまう」ものであることを踏まえると、古いブラウザを”サポート”するしないという考え方自体が不自然に思える。Tokenをつける一択では？

[toaruR]

クライアント側の実装には依存できないよなぁ

[coppieee]

IEのようなサポート終わってるやつはXSSし放題だろしTokenつけても攻撃防げないから、わざわざIEのためにTokenつける意味はないと思うぞ

[rryu]

リクエストヘッダのHostとOriginの比較で事足りるのではということなのだが、それを正確に送ってきてくれる環境に依存するのはちょっと怖いと思う。何か穴がある気が…

[kiririmode]

Samesiteのlax以上でCSRF耐性はどこまで獲得できるのか

[teppeis]

脆弱性対策で古い環境を考慮するかは各サービスで判断すること。例えばIEでログインもできないようなサービスがCSRF対策だけIE考慮する意味ないよね

[versatile]

状況がわかってありがたい。token ってなんともアドホックな感じなので根本解決してほしいが古いブラウザがある以上むずいよね・・・

[turanukimaru]

Springとかフレームワークの機能でTokenを付ける一択なんだけど…いい加減無くても良いようにならないかとは思うよなぁ。なんかのかみ合わせで動かなくなった時がキツイし俺らが好きだったWebはこんなんじゃなかったはず

[pixmap]

ありがたい。Tokenを無くす実装を正当化するのに、こんだけ考えないといけないなら、深く考えずにTokenを使うようにした方が現状まだ楽だな。その上でSameSiteも無意識に使うようにしておきたい。

[nemoba]

Cookie使わない副作用を持ってたらCSRF出来るから完全ではないつう話でもある。実用面はさておき