技術戦略部より、tipsやノウハウなど技術的な話題を発信いたします。MetadataChromeこんにちは。インフラ担当のいせです。2月4日リリース予定のChrome80からCookieのSameSite属性が明示されていない場合の挙動がLaxに変更される予定です。Metadataリクエストヘッダという機能が実装されています。このヘッダはリクエストが生成されたページとのオリジン間の関係をサーバ側に通知することができます。MetadataリクエストヘッダをWebサーバのアクセスログに出力することで、CookieのSameSite属性のデフォルトがLaxになった場合の影響を調査する方法を解説します。用語の定義この記事の中ではURLの構成要素をWHATWGの仕様に従って以下のように定義しています。Schemeプロトコルを指定します。HostFQDNやIPアドレスなど、基本的にはネットワーク上の識別名を指定します。Suffix(.comや.ne.jpなど)とその直前までを指します。通常は個人や組織が勝手に使用することができず、レジストラに登録する必要がある部分です。Portポート番号を指定します。Domainの関係によってCookieを送るかどうか制御する属性です。Domainが異なるページからリクエストが生成されたということになります。このときSameSite属性がNoneとなっているとwww.superdelivery.comのCookieが送信されますが、LaxにするとCookieは送信されません。80からはLaxに変わります。Jackingといった攻撃への耐性が高まるというメリットがあります。一方でこの変更により別サイトから遷移してきた際に、ログインのやり直しが必要になるなどの影響が考えられます。Domainが異なるサイトから生成されたリクエストにCookieが付与されるかどうかは、SameSite属性の値によって次のように変化します。Domainから生成されたリクエストでCookieを使用していないか」ということを確認する必要があります。これを漏れなく確認していくことは、なかなか骨の折れる作業ではないでしょうか。Domainから送られてきたリクエストかどうか、ある程度わかりそうな気もしますが、Refererヘッダは送られないケースが多々あったり、そもそもリクエスト生成元のタグ名を判別できなかったりと完璧ではありません。Metadataリクエストヘッダとは、一言で言うと「リクエストが生成されたコンテキストをサーバ側に通知するためのヘッダ」です。わかりやすく例えるなら、「Refererヘッダの進化系」と言ってしまっていいと思います。Domainから送られてきた」、「imgタグから画像ではないURLがリクエストされている」などといったことをサーバ側で把握することができます。Refererヘッダではプライバシーの問題があり、ブラウザ側でOFFにされてしまうケースがありますが、このヘッダはリクエスト生成元のURLは含まれないため、そのような問題は起こりにくくなっています。仕様としてはまだドラフトの段階ですが、Chromeでは2019年7月リリースのバージョン76から一部の機能が実装されています。※以下の説明は本記事執筆時(2020年1月24日)の情報を参照しています。仕様はドラフト段階なので変更になる可能性があります。この仕様では以下の4つのリクエストヘッダが定義されています。Sec-Fetch-SiteSec-Fetch-ModeSec-Fetch-DestSec-Fetch-UserSec-Fetch-Destヘッダ以外はChromeに実装されています。今回のSameSite=Lax化の調査で使用するのはSec-Fetch-SiteとSec-Fetch-Modeの2つです。Sec-Fetch-Siteこのヘッダはリクエスト生成元とリクエスト先のオリジン間の関係をサーバに通知するものです。オリジン間の関係には主に以下の3種類があります。Siteは少し意味が異なります。Domainが一致しているかどうかだけを見ており、Schemeは含まれません。www.raccoon.ne.jpのページ内のリンクをクリックして、www.superdelivery.comへ遷移した場合、このヘッダの値はcross-siteとなります。このヘッダが取りうる値は以下のとおりです。Siteの関係にあるときnoneURLをブラウザに入力したりブックマークをクリックするなど、ユーザーの操作から直接的に送信されたリクエストSec-Fetch-Modeこのヘッダはクライアントがリクエストを送信するときのModeをサーバに通知するものです。HTTPリクエストを送信する機能を持つHTMLタグやJavaScriptのオブジェクトは、Modeと呼ばれる属性を持ちます。Originであるときに「リクエストを送ることができるか」や「JavaScriptからレスポンスにアクセス可能か」がこのModeによって決定されます。HTMLタグやJavaScriptのオブジェクトはそれぞれ固有のデフォルト値がModeとして設定されていますが、ものによっては下記のように変更することが可能です。Standardという仕様に定義されています。このヘッダが取りうる値は以下のとおりです。Originへのリクエストの送信が可能です。リクエスト送受信の過程でAccess-Control-Allow-*ヘッダがないなどの違反があればエラーになります。JavaScriptでレスポンスを読み取ることができます。APIなどのデフォルトのModeです。Originへのリクエストの送信が可能です。content-typeJavaScriptでレスポンスを読み取ることはできません(ブラウザが画像などを画面に表示することはできる)。imgタグなどのデフォルトのModeです。Originへリクエストを送ることはできません。originにのみリクエストを送信することを強調したいときなどに使われます。navigateページが遷移する場合はこのモードになります。formタグやアンカータグでページ遷移する際にこのモードになります。nested-navigateiframeタグにて送信されるリクエストはこの値がヘッダに指定されます。Standardに定義されていません(iframeタグは本来navigateモードで動いています)。Metadataリクエストヘッダの仕様の中で定義されているもので、iframeヘッダを区別するために使用されています。websocketwebsocketにて送信されるリクエストはこのモードです。以下の2つのヘッダについては、今回の調査では使用しないので簡単に説明させていただきます。Sec-Fetch-Destこのヘッダはリクエストを生成した要素の種類をサーバに通知するものです。imgタグから生成されたリクエストの場合、このヘッダの値はimageとなります。このヘッダが取りうる値はたくさんあるので、いくつかよく使われそうなものを以下に取り上げます。imageimgタグなどから生成されたリクエストfontCSSのフォントとして読み込まれたリクエストdocumentページ遷移やiframeタグから生成されたリクエストSec-Fetch-Userユーザーが明示的に実行した操作から生成されたリクエストかどうかをサーバに通知するものです。URLを直接入力したり、ブックマークをクリックした場合にTrueになります。Trueのときは?1でFalseの場合はヘッダがつきません。アクセスログから調査する方法ここからはWebサーバのアクセスログでCookieのSameSite属性がLaxになったときの影響を調査していきます。79.0を使用しました。Metadataリクエストヘッダを出力するための設定を追加します。fetch_metadata_log上記のログ設定は今回の説明で必要な最低限の設定のみとなっています。送信元IPアドレスや時刻なども出力されないので、必要に応じて拡張して使用してください。テストページ検証のため、以下のようなページをhttps://fm-test.superdelivery.com/test.htmlを用意しました。※ここで登場するURLは検証のためのサンプルで、実際には公開されていません。</body></html>上記のページから以下のリクエストを送信することができます。APIアンカータグfromタグ(GET)formタグ(POST)imgタグiframeタグまた、ログを見たときにわかりやすいようにクエリ文字列を設定しています。OKを返すだけのページです。検証に当たって、予めChromeにはfm-test.paid.jpの以下のようなCookieを食わせておきます。上記のページから生成されたリクエストのアクセスログが以下になります。想定通りSameSite=Laxの場合は、GETメソッドのformタグとアンカータグのリンク以外から生成されたリクエストでCookieが付与されなくなってしまいました。APIでは明示的にCookie送信を指定しているにもかかわらず、SameSite=Noneだと落とされてしまうのはちょっと驚きました。Metadataリクエストヘッダから影響を確認ログを見ると以下の条件に当てはまらないリクエストがSameSite=Laxの影響を受けることがわかります。navigationのどちらかになりますので、SameSite=Laxの影響を受けません。したがって以下のような条件でログを調査することで、SameSite=Laxがデフォルト化されたときにCookieが送信されなくなるものを事前に発見することができそうです。Sec-Fetch-ModeがnavigateであるGETリクエスト以外でSameSite属性が明示されていないCookieまとめ今回はCookieのSameSite-Lax化の影響をWebサーバのアクセスログから調査する方法についてまとめました。弊社が運営しているサイトでは幸い影響がでるものはなさそうでしたが、事前に確認できたので安心してChrome80のリリースを迎えることができそうです。Excel以外でネットワーク構成図を書きたくなったのでPlantUMLとnwdiagを試してみました。