CookieのSameSite属性にまつわるあれこれ①
何が変わったって?
一部の界隈ではちょっとした騒ぎになっているCookieのSameSite属性について触れてみたいと思います。
2020年2月4日にリリースされた Chrome 80 からはCookieのSameSite属性の既定値が変わり、Webアプリの挙動になにやら影響を及ぼすので場合によっては対応が必要かもしれないよという話です。このバージョンアップは2月4日に一斉に切り替わるわけでなく、期間をずらしながら段階的に適用を拡大するようです。
具体的な変更点は、CookieのSameSite属性が未指定の場合「Lax」が指定されているのと同じ挙動になります。この「Lax」というのは(あとでもう少し詳しく説明します)、これまでは許可されていたCookieの送信を条件によっては制限する働きとなるのでWebアプリの挙動に影響を及ぼすことがあります。日本のブラウザシェアの約半数(2020年)を占めているChromeのこの変更の影響は大きなものと言えるでしょう。
なぜ変えたの?
CSRF (クロスサイト・リクエスト・フォージェリ) と呼ばれるWebアプリケーションの脆弱性の一つもしくはそれを利用した攻撃があります。
この攻撃を使われると、あるサービスのログイン中の状態に利用者が気付かない巧妙な手口で勝手にパスワードやメールアドレスを変更したり、知らない間に物品が購入されたりといった被害が起こる可能性があります。怖いですね。今回の変更の目的は、CSRF攻撃の抑止に一定の効果があるからだそうです。ネットをより安全に使えるようにChromeが計らってくれるのなら一般利用者にとっては喜ばしいことといえそうです。
ところが喜んでばかりもいられない
システム開発者、運用保守の立場からは喜んでばかりもいられません。Chrome の変更により既存のシステムが動作しないといったトラブルに見舞われないように影響調査や、不幸にも起きてしまった障害には迅速な対応が必要になってきます。
- ネットショップの決済処理ができなくなった!
- ログイン認証しても元画面に戻ってしまう!
といったトラブルを実際に見聞きしています。
どういった場合に問題になるの?どういった対策が必要になるの?
説明が非常に分かりやすかったのでこちらの記事を一部引用させてもらいました。
https://qiita.com/ahera/items/0c8276da6b0bed2b580c
CookieのSameSite属性は「Strict」「Lax」「None」の3つの値で制限の強さは「Strict」>「Lax」>「None」です。この値により、クロスサイトでの通信で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を使用する) |
「None」だと従来通りの動作となりますが、「Lax」だとPOST通信やiframe内に埋め込んだ場合にはCookieが送信されません。この制約が影響する例としては、決済や認証などで外部サービスを利用し、外部サイトからPOSTで戻ってくるサイトなどです。外部サイトから戻ってきたときにCookieが送信されないとユーザーが識別できなくなり連携処理がエラーになります。このようなサイトでは対応策としてSameSite=「None」を付けSecure属性を付与する方法が考えられます。
次回はCookieに SameSite属性、Secure属性を追加する方法を紹介したいと思います。
CookieのSameSite属性にまつわるあれこれ②