2019年 11月 02日

SameSite 属性結局どうすりゃいい?

tech

Chrome 80 (2020年2月予定) からは挙動が変更され、SameSite 属性がない (なにも対応していない場合) は SameSite=Lax の挙動がデフォルトになる。かなり厳しい制約が増えるので対応必須。

また、既存の挙動に戻すためには SameSite=None を指定する必要があるが、SameSite=None は Secure 属性が必須になる。

ということでいずれかが最低限必須

  • https 化 と Secure 属性
  • SameSite=Lax で問題ないサイトづくり

最低工数

  • 常時 https 化する
  • Secure 属性と SameSite=None 属性をつける

既に https 化されているなら最も手軽で追加の検証がいらない。

→ 今まで通りの挙動。CSRF 耐性は特になく、セキュリティは向上しないが不具合はでない

ちょっとは頑張れる

  • SameSite=Lax 属性をつける

→ ほぼ今まで通りだが、外部からのフォーム POST など、CSRF に繋がりそうなケースで挙動がかわり安全になる。XHR や iframe でも cross-site の場合はデフォルトでクッキーが送られなくなるので、対応のうえ全体で再度QAが必要

もっと頑張れる？

SameSite=Strict にすると、あらゆる外部サイトからのページ遷移のときにクッキーが送信されなくなる。最初に開くと必ず非ログイン状態になり、そのあと遷移するとログイン状態が復活したりする。ユーザー体験上、Strict をそのまま既存のセッションクッキーに適用するのは困難。

副作用が発生するクッキーだけを Strict クッキーに分けるような設計をすれば活用できるが、サイトのページ遷移から見なおす必要がある。

個人の見解では Strict を使うケースはないんじゃないかと思う。SameSite=Strict は銀の弾丸ではなく、アプリケーションの問題は CSRF だけではない。結局、総合的に他の施策も必要なので、SameSite=Strict している暇があったら他のことをしたほうが良さそう。

関連エントリー