2020年4月に入ったあたりから、ECCUBE2を使用している内部サービスで、決済代行会社の決済画面から戻った際になぜかセッションが無効となり、ページ遷移エラーもしくは自動ログアウトしてしまう現象が発生。
原因は結果的に、chrome80からのCSRF(クロスサイトリクエストフォージェリ)対策として、Cookieセット時にSameSite属性が適切に指定されていない場合、外部からそのサイトにPOSTなどでアクセスされた際に発行されたサイトのCookieが強制的に無効になるという仕様によるものでした。（エンジニアが気づいた）
※なお、多くの混乱を招いたようで、直後のChromeアップデートで当仕様は取り急ぎロールバックされた模様。
Googleからのアナウンスは、2019年11月には出ていた模様で、4月に入ったあたりから徐々にクライアントのChromeが80に強制アップデートされたようです。
現実に多くのショッピングサイトでは、決済時に決済代行会社の決済画面（特にリンクタイプ）で決済を行った後、処理結果受け取りのために決済完了画面からPOSTで戻って、パラメタを処理しています。
ECCUBE2のなどのカートシステムなどを利用している場合、大抵はページ遷移チェックがかかるため、この時決済画面に行く前のCookie情報が削除されていることから、セッション情報が判定できず、ログイン状態が無効となりセッションエラーもしくはログアウトという結果になります。
こういったサイトでは、対策として、
- Cookie発行時に「SameSite=None; Secure」をセットする
- httpsを利用する
ことで対応できます。
こちらに詳しくまとめていただいている方がいるので、適宜参照していただければと思います。
ECCUBE2のついては、すでにパッチが配布されていますで、ECCUBE2のサイト管理者は至急対応されることをおススメします。
なおこの配布パッチを充てると、具体的には、
- Cookieセット時に「SameSite=None;」を併せてセットする。この時、httpsなら「 Secure」を追加する
- SameSite=Noneが未対応のブラウザ用に、あらかじめ互換用のCookieを発行しておく。
- ECSESSIDが 現Cookieと対応しない場合は ECSESSID の Cookie が拒否されたと見なす
- 3の場合はあらかじめ発行しておいた互換用 cookie からセッションデータを読み込む
といった動作を行うようになります。
今回のアップデートについて、告知はされていたものの、もう少し具体的に影響を受ける対象事業者に対して大々的に告知してほしかったというのが正直なところ。
さらに言えば、決済代行会社も情報を早めに得て、影響を受ける顧客に周知するべきだったと思います。（リンクタイプを使っているクライアントはかなりいると思うし、、、）
うちが使っている決済代行会社は、通常結構この辺はきっちりしていて、こういう件が発生するときはかなり早めに連絡がくるのですが、今回に限ってはまったくもってノーマークだったように思います。念のため問い合わせたときに「特に障害情報は出ていません。どのような不具合でしょうか？」のような対応でしたからねー。