Chrome 80(2020年)以降、Cookie の SameSite 属性のデフォルトが Lax になり、古典的な POST CSRF はブラウザレベルで自動的に防がれるようになりました。
ところが、うつろい EC は外部の決済サービス(beauty-pay.example)と iframe 連携しているため、決済フロー中に Cookie が必要。SameSite=Lax だと iframe 越しに Cookie が送信されないので、開発者はセッション Cookie に SameSite=None; Secure を設定した。
これにより古典的な CSRF 攻撃面が復活。攻撃者は罠サイトから cross-site で POST すれば、被害者の認証 Cookie が添付されてしまう。
Cookie の SameSite 属性を切り替えて、各ケースで CSRF が成立するかしないかを観察してください。SameSite=None でのみ攻撃が成立するはず。
POST /account/email HTTP/1.1
Host: shop.utsuroi.example.com
Origin: https://beauty-news.evil
Cookie:
SameSite=None; Secure → cross-site POST でも Cookie が送信される → サーバは Cookie を見て「正規ユーザ」と判定 → CSRF 成立
3つのモード(Strict / Lax / None)それぞれで「攻撃を実行」を押して結果を比較してください。None でのみ CSRF が成立し、Strict と Lax ではブラウザが Cookie 自体を送らないため、サーバ側の脆弱性に到達できません。
つまり Chrome 80 以降のデフォルト(Lax)では古典的 POST CSRF は防がれます。逆に「サードパーティ連携のために None にした」場合、Token 等の追加対策がなければ簡単に攻撃される。