「SameSite」Cookieの不足はどのようにリスクを示すのですか？
現在、CookieにはHTTPOnly、Secure、SameSiteのフラグを設定できます。 HTTPOnlyフラグとSecureフラグの目的はかなり明確です。しかし、SameSiteスクリプトは正確に何をどのように防止しますか？
さらに、SameSiteフラグが使用されていない場合、「攻撃」または「誤用」が成功したシナリオはどのように見えますか？
実際の答えは、いつものようにすべきです：それはあなたの使用シナリオに依存します。
Strict値は、通常のリンクをたどっている場合でも、すべてのクロスサイトブラウジングコンテキストでブラウザからターゲットサイトにCookieが送信されないようにします。たとえば、GitHubのようなWebサイトの場合、これは、ログインしたユーザーが企業のディスカッションフォーラムまたはメールに投稿されたプライベートGitHubプロジェクトへのリンクをたどった場合、GitHubはしないことを意味しますセッションCookieを受け取り、ユーザーはプロジェクトにアクセスできなくなります。ただし、銀行のWebサイトでは、トランザクションページを外部サイトからリンクすることを許可しない可能性が高いため、Strictフラグが最も適切です。
デフォルトのLax値は、ユーザーが外部リンクから到達した後、ユーザーのログインセッションを維持する必要があるWebサイトのセキュリティと使いやすさの適切なバランスを提供します。上記のGitHubシナリオでは、CSRFが発生しやすいリクエストメソッド（POSTなど）でブロックしながら外部Webサイトからの通常のリンクをたどると、セッションCookieが許可されます。