CSRF(Cross-Site Request Forgery)攻撃について: https://zenn.dev/yktakaha4/articles/study_csrf_attack
要するに、（セッション）トークンをCookieに格納して、これで認証する運用の場合、
- フォームのPOST先のエンドポイントやWebAPIに対してのHTTPリクエストに、勝手にセッショントークンが送られてしまう（Cookieに入っていて、なおかつ同一のURLだから）。正規のアクセスではこの挙動を想定しているので、受信したトークンで認証が成立して問題ないが...
- 攻撃者はとにかくブラウザ経由で、フォームのPOST先のエンドポイントやWebAPIに対して要求を投げさせれば、アクセスが受け付けられてしまう（Cookieに格納されているので、勝手にセッショントークンが送られてしまうから）。
だから、Cookieによるトークンの送信に頼らずに、別の方法でリクエストにトークンを含ませる必要がある。
- HTMLのform hidden valueにトークンを入れておくと、form postでその値が一緒に送信される。これはハイジャック犯がこのトークン値を知ることが出来ないので、トークンなしまたは不正トークンで弾ける。
- WebAPIアクセスでも、トークンをJSONに入れておく（またはHTTP header）すれば、同様にWebAPI側でチェックして弾ける。
認証に使用するトークンをCookieで管理しなければ、セッション維持用のトークンと併用しても構わない。
- 基本的には
Synchronizer Token Patternを使う。これは上記の通りの手法。 - ほかに、
Double Submit Cookie Patternがあり、これはCookieにトークンを格納するので勝手に送信されてしまうが、一方でform hidden valueやJSONにも値が格納されるようにしておいて、サーバー側でこの値が一致することを確認する手法。- サーバー側でトークンの管理が不要（一致していればOK。もっとも固定SALTか何かで一方向ハッシュを行って一致を見たほうがいいかも）
- ただし、ブラウザに脆弱性があってCookieの値が漏洩した場合は、攻撃者がこの値を入手して攻撃を成立可能にしてしまうかもしれない。
抜け穴としては、WebUIとWebAPIの両方がhttpsを使って、かつCookieにSecure属性を付けて、
かつSameSiteをNoneにすることだけど、Noneにするのは...
というところから、これは現実的にできないと考えたほうが良いと思った気がする
CookieのSameSite属性と4つの勘違い(2022-10版)
SameSite Cookie について 「same-site」と「same-origin」を理解する
SameSite を Strict に設定すると、Cookie はファーストパーティ コンテキストでのみ送信されます」
ファーストパーティコンテキストとは、HTMLを受信した「サイト」と同じサイトに対して要求を投げる場合の事で、
「サイト」は、同一FQDNのほかにTLD+1またはeTLDのドメイン名を許容するってことらしい
なので、`https://localhost:<port>`が`SameSite=Strict`で許容されるのは、同一サイトだから。
SafariではすべてのサードパーティCookieをブロックするという話がここにつながるのか！ってなった
ついに見つけた！ やっぱり`ApplicationName`を使っている(`ApplicationDiscriminator`)。
そしてそれは`CookieOptions.Name`に設定されるので、この値をProgram.csでハードコーディングしておけばいい
PolyFitのドキュメント上は、`options.Cookie.Name = "TestWebAPICookie";`
みたいにハードコーディングした例を示しているので、こんな感じでやればいい