経緯
cookieにはSameSiteという属性があって、これがChrome80からデフォルトの扱いが変わった
- 正確には変わる予定だったが、コロナの影響で変更は先延ばしにされて、2020/07/14 のChrome84から変更されるようになった。なお、83, 81, 80 にも適時適用されたらしいです(なお、82は欠番)
何が変わったの?
SameSite属性が未指定の場合のデフォルト値が、None から、Lax に変更になった
そもそも、SameSite属性ってどういう属性なの?
ドメインAでset-cookieされた時に、ドメインBからドメインAにアクセスした時に、リクエストヘッダにそのcookieを入れるかどうかを決める属性
どういう振る舞いがあるの?
Strict、Lax、Noneの3つの値がある
- Strict: いかなる場合もcookieをリクエストに含めない
- Lax: POST、画像読み込み、XHR、iframeでのリクエストは、cookieをリクエストに含めない。通常のGETならば含める
- None: すべてのリクエストに含める。ただし、Chrome80からはSecure属性も必須
Secure属性って?
HTTPSの場合のみcookieの送信を許可するという設定
これは、通信経路上で、cookieを盗み見 & 書き換えが行われないための施策らしいです
なんでデフォルト値が、None から、Lax に変更になったの?
CSRF対策
CSRFってなんだっけ?
CSRF (クロスサイト・リクエスト・フォージェリ)。異なるドメインから偽装リンク等を通じて、ユーザに意図としない動作をさせる攻撃手法
インターネット古老勢だと知っているぼくはまちちゃん攻撃が有名
mixiにPOSTするURLを偽装して掲示板などに貼る -> mixiにログインしているユーザがそのURLを踏むと、POSTが行われて、意図しない書き込みが行われる。という攻撃
で、SameSite属性のデフォルトをLaxに変えることで、他ドメインからのPOSTを規制して、CSRF攻撃を潰すのが今回のアップデートの目的(らしいです)
他のブラウザの動向はどうなの?
Firefox
検討中
safari
2020 年 3 月に 3rd Party Cookie (ドメインをまたぐcookieのリクエスト)を完全にブロックするとアナウンス
SameSite属性をNoneにした場合は、設定によって挙動が変わるらしい
safari: MacOS 10.14とiOS 12の SameSiteバグ
SameSite=Noneを誤って、SameSite=Strictとするバグがあるので注意
これのために、Chrome80移行対応で SameSite=None に変更したい場合、サーバなりの設定でUAを見てiOSかMacOSの特定のバージョンの場合「 SameSite=None を設定しない」という処理を入れる必要がある
まだ、MacOS 10.14とiOS 12のユーザはそこそこいるはずなので...
古いブラウザでは SameSite=None が実装されていない
古いChromeやAndroidのUC Browserの古いバージョンでも、 SameSite=None が実装されていないため、正しく動かないという問題もある
これもiOSやMacOSのように、UAを見て SameSite=None を入れない。という方法を取る必要がある
この辺の対応をしないと困ることって何?
自前でコンバージョントラッキングをしていて、お客様のコンバージョンページにcookieトラッキングするようなタグを埋め込んでるサイトだと、 SameSite=None にしないと挙動しなくなる
トラッキング関係以外だとなにかあるのかな...?
