Djangoの組み込みCSRF保護で十分ですか？
DjangoはCookieを介してユーザーのマシンにCSRF保護トークンを設定します。次に、POSTリクエストでトークンを要求します。これら2つが一致しない場合、403を返します。
リクエストで送信したCookieとトークンの値の両方を手動で変更すると、リクエストは受け入れられます。 Djangoは、トークンの値がサーバーによって設定されたことを確認しません。Cookieとリクエストが一致する限り、403を返しません。
これは安全ではないようです。別のWebサイトが私のドメインを偽装して新しいCookieを設定し、リクエストで新しいCookieのCSRFトークン値を送信するとどうなりますか？ Djangoは2つを比較し、正当な要求を検討します。
これを異なる方法で実装するパッケージはありますか、それとも何か不足していますか？
Djangoは Double-Submit Cookie を使用しており、CSRF防止の安全な方法として受け入れられています。どうして？なぜなら、攻撃者がCSRF攻撃で提出されたCookieを制御することは不可能です 。CSRF攻撃は、実際、ブラウザはCookieを管理し、偽造されたHTTPリクエストのターゲットドメインに関連付けられたCookieを含めます。 XSSを使用して非HTTPOnly Cookieを読み取り、変更することは可能ですが、ほとんどすべてのCSRF対策はXSSによって損なわれる可能性があります。
あなたの質問に答えるには：
はい、アプリケーションにXSSの脆弱性がない限り、DjangoのCSRF保護システムはCSRF攻撃の成功を防ぎます。
DjangoのCSRF保護自体は壊れていません。一般に、多くのアプリケーションに十分であると考えられています。
しかし、実際に「二重送信されたCookie」モデルは、攻撃者がユーザーのブラウザにCookieを設定できる場合、CSRF保護が失敗することを意味します。攻撃者はCookieを設定し、トークンフィールドに同じ値を含むフォームをすぐに送信できます。 。これは、Cookieの強制からCSRFへのエスカレーションルートが存在する可能性があることを意味します。これは、よりセキュリティが重要なアプリケーションでは受け入れられない可能性があります。
Cookieの強制は、通常それ自体が単純な攻撃ではありません。同じ発生元のポリシーでは、通常、攻撃者のサイトが別のサイトにCookieを設定することを防ぐ必要があります。ターゲットサイトにXSSの欠陥がある場合は、明らかにCookieを設定または取得できますが、XSSがある場合は、すでに非常に大きく失っており、CSRFを心配する必要はありません。
これが当てはまる可能性があるのは、アプリケーション作成者として制御できない可能性があるホスティング要因です。
サイトがHTTPS上にあり、攻撃者がユーザーに対して中間者を使用している場合。 HTTPS Webサイトになりすますことはできませんが、ユーザーを同じホスト名のHTTPアドレスに誘導し、そこからブラウザーによってHTTPSサイトに送信されるCookieを書き込むことができます。 （これは
Strict-Transport-Securityヘッダーを使用して多少軽減できます。）サイトが
a.example.com上にあり、b.example.com上でXSSに対して脆弱な別のアプリケーションが実行されている場合、そのアプリケーションはexample.comのすべてにCookieを設定するために悪用される可能性があります。ブラウザからa.example.comのアプリに送信されます。
Cookieの設計上の弱点は、アプリケーションがCookieが元々一致するdomainプロパティとsecureプロパティで設定されたかどうか、および2つの同じ名前のCookieが異なるdomain/secure結果は基本的に未定義です。
「シンクロナイザトークン」および「暗号化トークン」（HMAC）のアプローチには、攻撃者が知らないサーバー側の秘密が含まれており、CookieがCSRFに強制されるのを防ぐことができます。
残念ながら、Djangoは、共有機能の完全な置き換えには適していません。CSRFメカニズムを改善または置き換えるには、それに依存するすべてのアプリを壊すことなく、醜い猿のパッチがたくさん含まれています。