Django では、ブラウザーを閉じたときにセッションが期限切れになるように指定できます (Chrome にはいくつかの注意事項があります)。CSRF Cookieに対してそれを行わないのはなぜですか?
CSRF トークンは漏えいしやすい (たとえば、誤って外部サイトへの投稿に入れるなど) と思われるので、質問します。私は何か誤解していますか?
カールがリンクした開発者のリストから回答を再投稿して、stackoverflow にも回答を追加します。
ブラウザを閉じたときに Cookie の有効期限が切れるように設定されている場合、ブラウザを閉じた (またはフォームを含むページをブックマークした) ユーザーがブラウザのキャッシュからそのページを読み込んでフォームを送信すると、CSRF エラーが発生します。このユース ケースをサポートする価値があるかどうかについては、私は意見が分かれていますが (たとえば、モバイル デバイスでは重要かもしれません)、ブラウザを閉じたときに Cookie の有効期限が切れるように設定しても、適切に構成されたサイトに多くのセキュリティ上の利点がもたらされるとは思えません。 (HTTPS、HSTS など)。
Django の CSRF 実装は、CSRF 情報をサーバー上のセッション情報と一緒に保存する他の多くの実装とは異なります[1]。CSRF メカニズムは、フォームで提供されたトークンと、ブラウザーで Cookie として提供されたトークンを照合することによって機能します。Cookie を「zzz」に設定しても、問題なく機能します。セキュリティは、特定の暗号化値がたまたま含まれているということではなく、攻撃者が Cookie を設定できないという事実に基づいています。
攻撃者がセッション間でユーザーの物理コンピューターにアクセスして CSRF トークンを盗む可能性があるという懸念がある場合、ブラウザーを閉じたときに期限切れになるように設定しても、次のセッションで使用される既知の値の Cookie を攻撃者が挿入することを防ぐことはできません。コンピューターが攻撃者によって物理的にアクセスされたユーザーのトークンを保護できるとは確信していません。
それでも、ブラウザーを閉じたときに Cookie の有効期限が切れるように設定しても、既存のユース ケース (モバイル ブラウザーが私の主な関心事) が壊れないことが説得力をもって示される場合、私はデフォルトの動作を変更することにオープンです。通常、悪意のないユーザーが無害な行動によって CSRF 警告をトリガーできる場合、それはバグと見なされます。
[1] Django の CSRF 実装は、他の実装とまったく同じようには機能せず、セッション cookie に関連付けられていないため、通常、ほとんどのペンテスター ツールであらゆる種類の誤報を引き起こします。
この質問は、以前に django-developers メーリング リスト で提起され、回答されています。