chrome80に伴うSameSite属性の変更について

Question

少し古い話ですが、chrome80に伴うSameSite属性の変更をについて疑問があり書かせていただきました。

私の知る限りですが、一般的な認証を伴うWEBサイト（ECやSNSなど）は、
Cookieを使ってステートレスなHTTPを１つのサービスとして見せるために、セッション管理をしていると思っております。

そして、下記のQitta記事にもあるように、ECサイト→決済処理外部サイト→ECサイトと外部サイトに一時的に遷移する場合に、
遷移元サイト側でのログイン状態を維持するため、SameSite明示的に書かず、デフォルト(none)で運用していたサイトも多くあると思っています。
今回のGoogleさんは、その暗黙のSameSiteのデフォルト値をnoneから変更した理解しました。

今後は、CSRFという脅威から身を守るために、こう言った外部とのPOSTのやり取りがあるECサイトは、cookie以外の方法でセッションを維持すべきだということですかね？
noneがセキュリティ的によろしくない、不正サイトからのCSRF攻撃をうけるよというのは分かったのですが、
では今後はどうやってその対策しつつ、外部サイトからの戻ってきた後のセッション維持をしていくべきなのかなと疑問に思いました。

https://qiita.com/ahera/items/0c8276da6b0bed2b580c

Answer 1

samesite=laxでもGETメソッドの場合はcookieが飛ぶので、単にAサイト→Bサイト→Aサイト（GET）ならログインは維持されます。

また、samesite=None および secure を指定したCookieなら、POSTでもCookieが飛ぶのでログインは維持されます。

通常はどちらかを使うものだと思います。ただし、参照されている記事のように、samesite=noneに伴うややこしい状態というのはあるのですが、それはなんとかするしかありません。

これに対して、「cookie以外の方法でセッションを維持」というのは一つの方法ではありますが、新規サイトならともかく、既存のサイトの場合は改修コストが大きすぎるでしょう。

Comments

[ryt-teratail]

ご回答ありがとうございます。
（徳丸様の徳丸本やTwitter等いつも拝見しておりましたので、ご本人から返信いただき感動しました。）

>samesite=laxでもGETメソッドの場合はcookieが飛ぶので、
>単にAサイト→Bサイト→Aサイト（GET）ならログインは維持されます。

Getメソッドで、cookieが飛ぶこと失念しておりました。
なぜかGetメソッドだとURLクエリとしてしか、セッション情報を渡さないといけないのでは？と思い込んでました。

>また、samesite=None および secure を指定したCookieなら、
>POSTでもCookieが飛ぶのでログインは維持されます。
こちらについては私も認識しておりました。
しかしながら、Noneと明示的に宣言した場合、cookieを用いてセッション管理をしているサイトですと、CSRFの脅威に対するリスクをはらむのかなと思っております。
（それをGoogleさんとしては無くしたいのでデフォルトをLaxに変えたものと理解しております）

＞これに対して、「cookie以外の方法でセッションを維持」
＞というのは一つの方法ではありますが、新規サイトならともかく、
＞既存のサイトの場合は改修コストが大きすぎるでしょう。
やはりそうですよね。ありがとうございます。

そうなりますと、既存で運営しているサイトで、その仕様としてCookieを用いてセッション管理実施かつ、外部サイト（決済機能等）とのインターフェースを　POSTメソッドで実装しているサイトと仮定すると。対応としては、
・samesite=None,secure にしてCSRFへの脅威からのリスクを許容するないし、
　セッション毎にサーバ側で別途セキュリティ強化策を講じる（例：セッション毎に画面の遷移情報などをサーバで保有する）などを行う
・外部サイトからの戻りのインタフェースをGetメソッドに変更することで、Cookieが送信されるようにする
の大きく分けて２つという感じでしょうか。

こうやって返信を書いていて、私がまだ理解が足りないなと感じたのは、
そもそもCSRFの対策としてsamesiteをNoneからLaxへ変更したとしても、
GetメソッドだとCookieが送られてしまうという仕様である点が腹に落ちていません。

Getメソッドで、更新処理（退会処理、購入処理など）をWEBサーバ側で実施していると、CSRFの被害には合うのではないか？と私の中でもやもやしているので勉強してみます。

ありがとうございました。

[ryt-teratail]

>Getメソッドで、更新処理（退会処理、購入処理など）をWEBサーバ側で実施していると、
>CSRFの被害には合うのではないか？と私の中でもやもやしているので勉強してみます。
自己解決しましたので記載をしておきます。私の記載したことは技術的にはできるが、RFCでも記載がありますがGetメソッドの冪等性に反しており、CSRF以前にサイト大きな問題ですね。。。失礼しました。

だとすると、２つ目の箇条書きはGetメソッドに変えるだけでなく、
外部サイトからの当該サイトに遷移する際のURLをPostからGetに変える時点で、
クッションページのような画面を用意し、その後ユーザの意思をformなどを利用して確認し、
コミットしてもらう（POSTする）というものですね。

[ockeghem]

Samesite属性ができる前からCSRFの脅威は元々あり、それに対してトークン等による対策をしてきたわけですから、それは何ら変わりません。従来どおりの対策を確実に実施すればよいことです。