CookieのSameSite属性にまつわるあれこれ②
前回はChrome 80 からCookieのSameSite属性の既定値が変わることになった背景とその影響を簡単にまとめてみました。このChromeのアップデートにより、
- ネットショップの決済処理ができなくなった!
- ログイン認証しても元画面に戻ってしまう!
といったトラブルに遭遇してしまった場合、Webアプリの管理者が取れる対応のひとつとして、発行しているCookie に SameSite=「None」を付けSecure属性を付与する方法が考えられます。ただしこの方法はGoogleがネットをより安全に使えるようにとChrome 80 で変更した目的に反していますので他の回避策があるならそちらを検討したほうがよいかと思います。
Webアプリの用途や、何で作られ何で動かしているのかによって様々な対応方法があると思います。ここでは既存のWebアプリは修正せず、Webアプリを動かしているWebサーバーソフトウェアのひとつ Apache のコンフィグ設定で対応する方法を紹介してみたいと思います。IIS、nginx 他のWebサーバーをご利用の管理者さんは他の方法をお探しください。あとCookie に SameSite属性を付与するにはSecure属性も必要ですのでWebアプリがSSLで通信できていることが前提になります。
Apache で Cookie に SameSite=None, Secure を付与する
今回動作検証を行った環境
CentOS 6.5
SSL使用
Apache 2.2.15
ApacheでCookie に SameSite属性を付与するには.htaccess
や ssl.conf のファイルで設定します。ここでは ssl.conf に設定してみます。
ssl.conf
# Cookieに SameSite属性、Secure属性を追加し SameSite=None;Secure と設定します。
Header edit Set-Cookie “^(?!.*(\s+|;)(?i)SameSite=)(.*)” “$0; SameSite=None; Secure”
設定内容の解説をします。Header edit Set-Cookie で HTTPヘッダーの Cookie 情報を編集しています。この正規表現では Cookie に SameSite属性が付いていない場合に SameSite=None; Secure を追加することになります。もしはじめから Cookie に Secure属性を付けていたなら Secure は追加しないよう設定を修正してください。設定後、Apache (httpd) を再起動して設定が反映しているか確かめてみます。
Cookie の確認方法
Chromeのデベロッパーツールで確認してみます。
・右上の「︙」アイコンをクリックして「その他のツール」-「デベロッパーツール」
・Windowsなら「F12」キー
上記のどちらの手順でデベロッパーツールを起動しWebアプリをブラウザで表示してみます。
上の図のようにWebアプリからのレスポンスヘッダーにある Set-Cookie の各キーに SameSite=None; Secure が追加されていることを確認できたらOKです。あとはWebアプリの動作確認を行い問題が解消しているかご確認ください。
一部のブラウザは SameSite=None の互換性がない?
上記の手順で対応完了、としていたところに次の懸案事項があることが分かりました。
iOS12 / macOS 10.14 のSafari / Chrome5 / Chrome6 / Android版 UC Browser < 12.13.2 の一部は SameSite=None の挙動が異なります。具体的には、Cookieを拒否されたり、SameSite=「Strict」と扱うそうです。このことは SameSite=None を付けることで逆に問題を引き起こしてしまうことにつながります。対策としては、これらのブラウザにSameSite=None を指定しないよう UserAgentを判別して、SameSite属性を付与しない方法があります。
先ほどと同様に、ssl.conf に追加設定してみます。
ssl.conf
# Cookieに SameSite属性、Secure属性を追加し SameSite=None;Secure と設定します。ただし、
# iOS12 / macOS 10.14 のSafari / Chrome5 / Chrome6 / Android版 UC Browser < 12.13.2 の一部は SameSite=None の挙動が異なるため、UserAgentを判別して、SameSite属性を付与しません。
# 参考: https://catchjs.com/Blog/SameSiteCookies
#
BrowserMatch “iPhone OS 12_” SAMESITE_SKIP=1
BrowserMatch “iPad; CPU OS 12_” SAMESITE_SKIP=1
BrowserMatch “Chrome/[5-6]” SAMESITE_SKIP=1
BrowserMatch “OS X 10_14_.*Version/.*Safari” SAMESITE_SKIP=1
BrowserMatch “OS X 10_14_.*(KHTML, like Gecko)” SAMESITE_SKIP=1
# Skip all UCBrowser
BrowserMatch “UCBrowser/” SAMESITE_SKIP=1
# Allow on 12.13.2 and higher
BrowserMatch “UCBrowser/12\.13.[2-9]” !SAMESITE_SKIP
# Allow on 12.14-12.19 and higher
BrowserMatch “UCBrowser/12\.1[4-9]” !SAMESITE_SKIP
# Allow on remaining 12.*
BrowserMatch “UCBrowser/12\.[2-9]” !SAMESITE_SKIP
BrowserMatch “UCBrowser/1[3-9]” !SAMESITE_SKIP
BrowserMatch “UCBrowser/[2-9][\d]” !SAMESITE_SKIP
# SAMESITE_SKIP フラグが立っていない場合は設定します。
Header edit Set-Cookie “^(?!.*(\s+|;)(?i)SameSite=)(.*)” “$0; SameSite=None; Secure” env=!SAMESITE_SKIP
UserAgentを変えてCookieを確認してみる
先ほどと同じようにChromeのデベロッパーツールで確認してみます。デベロッパーツールの左上にある「︙」のアイコンをクリックし、出てきたメニューから「More Tools」-「Network conditions」と選択します。表示された画面の「select automatically」のチェックボックスのチェックを外すと、その下に直接UserAgentを設定することができます。
動作確認に使いたいデバイス、ブラウザ、バージョン別のUserAgentは検索すればすぐ出てきます。動作確認を行いたいブラウザのUserAgentを設定して、Webアプリにアクセスし 送られてきたCookie に SameSite属性が付いていなければOKです。
設定方法や互換性の問題は次のサイトを参考にさせていただきました。ありがとうございます。
https://www.chromium.org/updates/same-site/incompatible-clients
https://catchjs.com/Blog/SameSiteCookies
ここにも新型コロナウイルスの影響が
まだ多くの対応できていないWebサイトで問題が発生する可能性が懸念されており、新型コロナウイルスの影響でIT現場にも混乱が見られることからChrome 80 の変更を一時撤回するそうです。
米Googleは4月3日(現地時間)Google、「Chrome 80」から導入されている“SameSite Cookie”の変更を一時撤回
https://forest.watch.impress.co.jp/docs/news/1245512.html