自分のドッグフードを食べるなんて最高だ！！！」。
特定のブラウザ（Chromeなど）を挙げるまでもなく、最近のブラウザはクッキーのセキュリティ設定にうるさくなっています。
その一例がSameSite Cookieの設定です。例えば、Chromeにこの設定がない場合、デフォルトのSameSite=Laxが使用されます。
しかし、これを望まない場合はどうなるのか？答えは、アプリケーションのコードを変更して、使いたい設定を反映させることです。しかし、これが簡単にできない場合はどうなるでしょうか？レガシー・アプリケーションかもしれません。
その答えは、EdgeADCのflightPATHコンテンツ切り替え機能を使うことです。
悪名高いWordPressのWooCommerceがIframeで動作する問題
そこで、私たちが使っているWordPressアプリケーションがIframeで動作しているという問題が発生した。(理由は聞かないでください）。
アプリケーションは、SameSiteが設定されていないセッションクッキーを使用していました。
アプリケーションは、Dockerコンテナ内で提供されるデフォルトのWordPressシステム内で実行される。
これを修正する方法をいくつか検討しましたが、私たちの変更がすべてのクッキーで正しく機能しなかったため、flightPATHを使って修正を試みることにしました。
だから、こうしたんだ。
以下のように、問題のある 3 つのクッキーに SameSite=none を追加する flightPATH ルールを作成しました。
最初に作成するflightPATHルールは以下の通り：
次に、2つ目を作る。
最後に、最後のものを作る。これはご覧のように少し異なる定義をしています。WordPress / WooCommerceはランダムな値を割り当てるので、その値が何であるかわからないため、ワイルドカード（*）を追加しました。
この時点で、「おいおい、ワイルドカードが使われている時点で、これは安全ではないじゃないか！」とおっしゃることでしょう。サイトの安全性が若干低くなることは理解していますが：
- すべてHTTPSで実行されている
- アプリケーション・ファイアウォールを運用しています
- コンテナ化されたOSであり、キーファイルがイミュータブル（不変）であるという事実によって強化されている。
そして、SameSiteについて復習が必要な方のために…
クッキーのSameSite設定とは何ですか？
SameSite Cookie設定は、クロスサイトリクエストでCookieが送信されるタイミングを制御し、クロスサイトリクエストフォージェリ（CSRF）攻撃のリスクを軽減するのに役立ちます。以下は、その仕組みの内訳です：
クロスサイトリクエストとは何か？
クロスサイトリクエストとは、あるウェブサイトから別のウェブサイトへのリクエストのことです。例えば、あるアプリケーションにログインしていて、ニュース記事へのリンクをクリックした場合、それはクロスサイトリクエストです。簡単に言うと、あるサイトから別のサイトにリンクするリクエストです。
SameSite設定とは何ですか？
SameSite 設定はクッキー属性で、クロスサイト・リクエストでクッキーを送信するかどうかを制御するために使用できます。SameSite 設定には 3 つの値があります：
- SameSite=Strict：クッキーは、クッキーを設定した同じサイトへのリクエストでのみ送信されます。
- SameSite=Lax：Cookieは、Cookieを設定した同じサイトへのリクエストや、iFrameなどで同じページに埋め込まれたサードパーティのサイトへのリクエストと一緒に送信されます。
- SameSite=なし：クッキーを設定したサイトに関係なく、すべてのリクエストでクッキーが送信されます。
なぜSameSiteの設定が重要なのか？
SameSite設定は、クロスサイトリクエストフォージェリ（CSRF）攻撃のリスクを軽減するのに役立つため、重要です。CSRF攻撃は、ユーザーのブラウザがすでにウェブサイトにログインしているという事実を悪用するサイバー攻撃の一種です。CSRF攻撃では、攻撃者はユーザーを騙して、たとえユーザーにそのつもりがなくても、ログインしているウェブサイトにリクエストをさせることができます。これにより、攻撃者はユーザーのデータを盗んだり、その他の悪意のあるアクションを実行したりすることができます。
