Chrome 80で何が変わるのか
2020年2月4日にGoogle Chrome 80がリリース予定されています。
Google Developersの 新しい Cookie 設定 SameSite=None; Secure の準備を始めましょう の記事にあるように、
このバージョンから以下のように変わります。
- Chrome 79まで
- SameSiteが未指定の場合
Noneと同じになる。
- SameSiteが未指定の場合
- Chrome 80から
- SameSiteが未指定の場合
Laxと同じになる。 - SameSiteに
Noneを指定する場合は、Secure属性が必須となる。
- SameSiteが未指定の場合
※Secure属性とは、HTTPS上だけで読み取りができるCookieです。
なぜ変わるのか
先のGoogle Developersのブログに書いてあることをざっくりまとめると以下のようになります。
- SameSiteを使えるようにした。
LaxかStrictを指定すればCSRFは防げる。 - でも誰も使っていないので大多数のサイトにCSRFの脅威がある。
- ならばデフォルトを
Laxにしてしまえ。そうすれば大多数のサイトはCSRFについて安全だ。 - クロスサイトで使いたきゃ明示的に
Noneを指定した上でSecure属性を付ければいい。
SameSiteとは？
CookieのSameSite属性はStrict Lax Noneの3つの値を取ります。
値により、クロスサイトでの通信でCookieの送信を制御します。
設定値
- Aサイト…Cookieを発行したサイト
- Bサイト…Aとは別ドメインのサイト
| 設定値 | 効果 |
|---|---|
| Strict | Aサイトに対し、Bサイトからどのようなリクエストがあっても、発行したサイトでCookieヘッダーに含めない (Cookieを使用しない) |
| Lax | Chrome 80からのデフォルト値。 Aサイトに対し、BサイトからのPOSTや画像読み込み、XHR、iframeでのリクエストでは発行したサイトでCookieヘッダーに含めない (Cookieを使用しない) GETであればCookieヘッダーに含める (Cookieを使用する) |
| None | Chrome 79以下や他ブラウザのデフォルト値。 Chrome 80からこの値を設定する場合、Secure属性も必須となる。 Aサイトに対し、Bサイトからどのようなリクエストがあっても、発行したサイトでCookieヘッダーに含める (Cookieを使用する) |
図にすると以下のようになります。
Strict
外部サイトからのアクセスではCookieを送らない。
Lax
外部サイトからのアクセスはGETリクエストのときだけCookieを送る。
None
従来通りの動き。
セキュリティ上の効果
CSRF対策になります。
CSRF (クロスサイト・リクエスト・フォージェリ) とは、
WEBサイトがユーザー本人の意図した動作であることを検証していないためにおこる脆弱です。
- たとえば会員の退会ページを
https://example.com/mypage/delete/で用意し、
ボタン操作でsubmit=1が送信されて退会処理が実行される仕様の場合、
パラメータが誰でもわかるので、外部に用意された悪意のあるフォームからも
同じパラメータで送信することができます。 - ログイン済みの会員ユーザーがその状態で悪意のあるフォームを操作してしまうと
意図せず退会されていまいます。
CSRF対策でよくある方法は、
本人しかわからないパラメータ（ランダム文字列など）を発行して一緒に送信することで
ボタン操作が本人にひもづく動作であることを確認しています。
- SameSite (
LaxorStrict)の場合、ユーザー本人にひもづかないようにしてしまうことでCSRF対策としています。
ユーザー本人かどうかWEBサイトが知るにはCookieに識別情報に持つことで実現しているのですが、
外部の悪意のあるフォームなどからの送信でそのCookieを付けないようにすれば
WEBから見ればログインしていない人が退会しようとしていますので、エラーとなります。
このようにCSRFに一定の効果があることから、Chrome 80からデフォルトをLaxとして扱うようになります。
対策
特に何もしなくても大丈夫なサイト
- 特にCookieを発行していないサイト。
- 外部からPOSTや画像のロード、XHR、iframeでの呼び出しが無いサイト。
- 外部からPOSTなどされてくるけど、特にCookieが読み込めなくても問題ないサイト。
上記以外のサイトでは対策が必要になりそう
SameSite=Noneを付けた上でSecure属性を付与をすることで、従来通りの動作になります。
画像やXHR、iframeなどを使ってユーザートラッキングのCookieを発行しているサイト
- いわゆるサードパーティCookieを発行しているサイト。
ECやサービス系の会員サイトで、決済や認証などで外部サービスを利用し、外部サイトからPOSTで戻ってくるサイト
- 決済でいえばクレジットカードの3Dセキュアが本人認証のためにイシュアのサイトにリダイレクトし、
戻るときにPOSTしている可能性があります。 - ユーザー識別をCookieで行っている場合、外部サイトから戻ってきたときにユーザーが識別できなくなります。
つまり大抵はこういった外部サービスとの連携処理がエラーになります。
ECサイトであれば注文ができないことになるので損失が出る可能性があります。 - ユーザー識別CookieはファーストパーティCookieですが、SameSiteは特にファーストパーティ、サードパーティかは区別しません。
「サードパーティCookieだけだから関係ないんじゃない？」と誤解している人も周りに多くいました…。
テスト方法
- Chrome 79以下では
chrome://flags/を開き、以下をEnabledにしてブラウザを再起動します。SameSite by default cookies-
Cookies without SameSite must be secure
注意点
- ただしChrome 78, 79では想定通り動いたり動かなかったりするような動作をします。
- これはChrome 78以降は「POST+Lax」のとき介入サポートとして、
Laxであっても2分間はCookieを送信するというChrome独自の動作によるものです。 - この2分間の介入サポートは将来的に削除され、本来のLaxの動きになる予定です。
- テストする際には2分待ちましょう。
コマンドラインで--enable-features=ShortLaxAllowUnsafeThresholdを付けると変えられるみたいです。(未検証) - Chrome Platform Status - Cookies default to SameSite=Lax より。
この2分間という介入サポート、かえって混乱を招くのでは…（ボソッ
まとめ
-
2020年2月4日リリース予定のChrome 80からSameSite属性のないCookieは
Laxになる。 - 外部からPOSTや画像のロード、XHR、iframeでの呼び出しでCookieは付かなくなる。
- つまりCookieを使った会員識別をしている際、外部からアクセスされると識別できなくなる。
- サードパーティCookieを使っているサービスのほか、ファーストパーティCookieでも
ECやサービス系の会員サイトで外部と画面上で連携している場合は早急に確認と対策が必要。
