Samesite CookieはCSRFおよびXSSに対する十分な保護になりますか？

Question

私はこのアイデアが好きであり、CSRFとXSSに対する新しい形の保護をもたらすか、少なくともそれらの攻撃を軽減するように思われます。

では、この保護はどの程度効果的でしょうか？

SameSite-cookiesは、ドメイン上でCookieを送信する方法を定義するメカニズムです。これはGoogleによって開発されたセキュリティメカニズムであり、現時点では Chrome-dev（51.0.2704.4）に含まれています。 SameSite-cookieの目的は、CSRFとXSSI攻撃を防ぐことです。ここでドラフトを読むことができます。（ソース）

Anders · Accepted Answer

まず、 Chrome からの定義：

同じサイトのCookie（née "First-Party-Only"（née "First-Party"）））を使用すると、サーバーは、特定のCookieが同じリクエストから送信されたリクエストでのみ送信されることを主張することにより、CSRFおよび情報漏洩攻撃のリスクを軽減できます。登録可能なドメイン。

では、これは何を防ぐのでしょうか？

CSRF？

同じサイトのCookieは、CSRF攻撃を効果的に防止できます。どうして？

同じサイトとしてセッションCookieを設定した場合、リクエストはサイトから発信された場合にのみ送信されます。そのため、攻撃者がサイトhttp://malicious.comにリクエストを投稿するhttp://bank.com/transfer.php?amount=10000&receiver=evil_hackerに被害者を誘導する標準的なCSRF攻撃は機能しません。 malicious.comはbank.comと同じオリジンではないため、ブラウザはセッションCookieを送信せず、transfer.phpは被害者がログインしていないかのように実行されます。

これは、X-Csrf-Token HTTPヘッダーを設定してCSRFから保護する方法とよく似ています。この場合も、リクエストがドメインから発信された場合にのみ送信されるものがあります。 same-siteプロパティは、セッションCookieをCSRFトークンに変換します。

問題は解決しましたか？まあ、ちょっと。いくつかの注意点があります：

これは、この機能を実装するブラウザでのみ機能します。これまでのところ、ほとんどありません。少し古いブラウザを使用するすべての人をバスの下に投げたくない場合を除き、古い形式のCSRFトークンを実装する必要があります。
さらに細かい制御が必要な場合は、これでは不十分です。フォーラムなど、信頼できないユーザーコンテンツを表示するシステムを実行している場合、ユーザーの投稿からのリクエストを有効なものとして扱わないでください。誰かがhttp://myforum.com/?action=delete_everythingへのリンクを投稿した場合、ユーザーがクリックしただけでは何も削除しないようにする必要があります。従来のCSRFトークンを使用すると、使用するタイミングを正確に制御できます。同じサイトのCookieでは、できません。
昔ながらのCSRF保護と同じ古い警告が引き続き適用されます。 XSSの脆弱性がある場合、この世界でのCSRF保護はあなたを救いません。

そうは言っても、同じサイトのCookieは、従来の防御策と一緒に使用することをお勧めします徹底的な防御策として。

XSSおよびXSSI？

同じサイトのCookieは、通常のXSS攻撃からユーザーを保護するものではありません。ハッカーがあなたのサイトをだましてサイトのURLからスクリプトをエコーするように管理した場合、それはオリジンから送信されたものとして実行されます（結局のところそうです）。したがって、セッションCookieは引き続き、挿入されたすべてのリクエストとともに送信されますあなたのドメインになります。

投稿の引用を注意深く読むと、末尾にIが付いたXSSIであり、XSSではないことがわかります。 Iはインクルージョンを表し、XSSIはXSSと関連していますが、XSSとは異なります。ここはXSSIの良い説明であり、XSSとXSSの違いを説明しています。

XSSIは、他のドメインやサーバーでホストされている画像やスクリプトなどのリソースをブラウザーがWebページに含めることを妨げないという事実を利用したXSSの形式です。 [...]たとえば、Bank ABCのサイトにユーザーのプライベートアカウント情報を読み取るスクリプトがある場合、ハッカーはそのスクリプトを悪意のあるサイト（www.fraudulentbank.com）に含めて、ABCのサーバーから情報を取得することができます。 ABC銀行のクライアントがハッカーのサイトにアクセスします。

同じサイトのCookieは、XSSIからユーザーを保護します。これは、セッションのCookieがスクリプトの要求と共に送信されず、機密情報が返されないためです。ただし、通常のXSSでは違いはありません。

Jamesernator · Answer

これは、サポートするブラウザと、サイトの現在の設定方法によって異なります。

この機能をサポートするブラウザのみを厳密にサポートしている場合は、次のいずれかを実行することで十分です。

トップレベルのナビゲーションでCookieを送信しない（外部からログインしたページにリンクできないため、これは非常に制限的です）
noオペレーションがGET（または任意の safe メソッド）を使用してオペレーションを実行することを確認します。それ以外の場合は、前の答え

トップレベルのナビゲーションなしで外部サイトからログインしたページにアクセスできる場合は、SameSite: 'strict'が適している可能性があります。このオプションを使用すると、指定されたCookieがanyリクエストで送信されなくなり、クロスオリジン（リンクのクリックなど）。

外部サイトからログインページにリンクする必要がある場合は、GET（または任意の safe）からno観察可能な変更が発生することを確認する必要があります。 method）をサーバーに送信し、代わりにSameSite: 'lax'を使用する必要があります。この制約を確実にすることができれば、ユーザーが送信したリンクでも安全です（とにかくCRSF攻撃から）。

これらの制約のいずれかを確実にすることは、（最新のブラウザー要件に加えて）既存のコードベースではおそらく簡単ではないので、CSRFトークンをすでに使用している場合は、多くの場所でまだGETは、操作をトリガーするためのものです。

新しいプロジェクトを開始していて、機能をサポートしていないブラウザーをサポートする予定がない場合は、基本的にコードが1行だけなので、検討する価値があります。'lax'の両方を知っていることを確認してください。および'strict'モードと、両方のモードで従う必要がある制限。

SameSite: 'strict'について：SameSite: 'strict'を使用していて、ユーザーがサイトの制限された部分への外部リンクをクリックすると、続行するかどうかを尋ねるスプラッシュ画面が表示される可能性があります。リソースが外部からリンクされることを意図していない場合、リンクが攻撃/トリックである可能性が高い場合、これを強くお勧めします。

ユーザーが続行することを選択した場合にこのようなスプラッシュ画面を表示することで、サイトで続行をクリックするとSameSite- cookieが送信されるため、ユーザーは再びログインする必要はありません。

リダイレクトが自動的に行われるようにする場合は、安全であることがわかっているページにRefresh: 0ヘッダーを追加することもできます（これは、特定のページが実際にかどうかを確認する絶好の機会でもあります上記のスプラッシュ画面にフォールバックしない場合は、外部でリンクしても安全です。これとSameSite: 'lax'の主な欠点は、ナビゲーションを2回繰り返すことになることです。