はじめに

以前「.NET Core 3.1 Preview 1が発表」の記事において、「SameSite cookieに重大な変更があった」という話がありました。

そもそもSameSite cookieとは何か？今回の.NET Coreのアップデートで何が変わったのか？といった点についてもう少し掘り下げられそうなので今回はそれらについて解説したいと思います。

SameSite属性とは

SameSite属性とは、Cookieに付与する属性のです。

CookieはWebサイト等から発行され、情報をユーザーのPC上に保存するデータで、これを読み出すことで例えば以前ログインしたページのセッションIDを使って自動再ログインを行うことなどができます。

しかし、このCookieは特に設定しなければ同じドメイン上のスクリプトからならどこに対しても読み出しが可能で、それゆえにXSSやCSRFなどによって意図しない場所にCookieの情報を公開させられ、アカウントの乗っ取りが行われることがあります。

これに対する対策がSameSite属性で、この属性の設定によってCookieを他のドメインに対して読み出しが行えないようにすることができます。

SameSite属性にはNoneとLaxとStrictの３つの種類があり、Laxにおいてはその読出し規制を緩めにかけ、他のドメインに対するGETメソッドでの通信においてはクッキーの読み出しを許可します。

が、Strictの設定をしておくとどんなメソッドでも、他のサイトからはCookieを読み出せないようにしてくれます。

一般的には、なるべく他のドメインからCookieにアクセスさせたくはないものの、そうすると他のドメインから自分のドメインへのリンクを辿ってやってきたときにCookieの読み出しが行えないので、自動ログインができないなどといった弊害が起きるため、Laxの設定にするのが定石だと考えます。

今回の仕様変更

Treat cookies as SameSite=Lax by default if no SameSite attribute is specified
Googleによると、Chrome 80からSameSite属性をデフォルトとしてLaxとして扱うことにするそうです。
つまり、Chromeを使用している際にCookieにSameSite属性が付与されなかった場合、そのCookieのSameSite属性がLaxであるものとして扱われることになるそうです。

参考:Incrementally Better Cookies
参考:Cookies default to SameSite=Lax

.NET Core3.1 Preview 1への影響

Browsers like Chrome and Firefox are making breaking changes to their implementations of SameSite for cookies.
These changes impact remote authentication scenarios like OpenIdConnect and WsFederation which must now opt out by sending SameSite=None.
同様の動きはFireFoxにおいても起きているようで、これらのブラウザーのアップデートによってOpenIdConnectやWsFederationを使う場合に影響してくるそうです。
例えば、これまで.NET Core内でSameSiteMode.Noneを指定したときCookieにはSameSite属性を付与しないという挙動で実装してきました。
しかし、今回デフォルト値が設定されることになったため、SameSiteMode.Noneを指定したときには明示的にCookieにSameSite属性にNoneを設定するよう挙動が変更されることになりました。
Applications that interact with remote sites such as through 3rd party login will need to test those scenarios on multiple browsers, as well as apply the CookiePolicy browser sniffing mitigation discussed below. See below for testing and browser sniffing instructions.
そのため、リモートのサイトへのログインを行っているアプリケーションを開発している場合は、一度影響を受けていないかチェックすることを推奨されています。