影響
クロスサイト リクエスト フォージェリ (CSRF) を使用すると、攻撃者は被害者のブラウザをだまして、被害者が現在認証されている別の Web サイトで望ましくないアクションを実行させることができます。ブラウザはリクエストに Cookie などのアンビエント資格情報を自動的に含めるため、攻撃者はユーザーの知らないうちに状態を変更する操作 (パスワードの変更、データの削除、トランザクションの開始など) を偽造する可能性があります。
根本原因
CSRF の根本的な原因は、リクエストの発信元 [S1] に関係なく、ドメインに対してリクエストが行われるたびに、そのドメインに関連付けられた Cookie を送信するという Web ブラウザーのデフォルトの動作にあります。リクエストがアプリケーション自身のユーザー インターフェイスから意図的にトリガーされたかどうかを具体的に検証しないと、サーバーは正当なユーザー アクションと偽造されたアクションを区別できません。
Django CSRF 保護メカニズム
Django は、ミドルウェアとテンプレートの統合 [S2] を通じてこれらのリスクを軽減する組み込みの防御システムを提供します。
ミドルウェアのアクティベーション
django.middleware.csrf.CsrfViewMiddleware は CSRF 保護を担当し、通常はデフォルトの [S2] で有効になります。これは、CSRF 攻撃がすでに処理されていることを前提とするビュー ミドルウェア ([S2]) の前に配置する必要があります。
テンプレートの実装
内部 POST フォームの場合、開発者は <form> 要素 [S2] 内に {% csrf_token %} タグを含める必要があります。これにより、一意の秘密トークンがリクエストに確実に含まれるようになり、サーバーはそれをユーザーのセッションに対して検証します。
トークン漏洩のリスク
実装の重要な詳細は、外部 URL [S2] をターゲットとするフォームに {% csrf_token %} を含めないことです。これを行うと、秘密の CSRF トークンが第三者に漏洩し、ユーザーのセッション セキュリティ [S2] が危険にさらされる可能性があります。
ブラウザレベルの防御: SameSite Cookie
最新のブラウザでは、Set-Cookie ヘッダーに SameSite 属性が導入され、多層防御の [S1] レイヤーが提供されています。
- 厳密: Cookie はファーストパーティ コンテキストでのみ送信されます。つまり、URL バーのサイトが Cookie のドメイン [S1] と一致します。
- 緩い: Cookie は、クロスサイトのサブリクエスト (画像やフレームなど) では送信されませんが、標準リンク [S1] をたどるなど、ユーザーが元のサイトに移動したときに送信されます。
FixVibe がそれをテストする方法
FixVibe には、ゲート付きアクティブ チェックとして CSRF 保護が含まれるようになりました。ドメイン検証後、active.csrf-protection は、検出された状態変化フォームを検査し、CSRF トークン形式の入力と SameSite Cookie シグナルをチェックしてから、影響の少ない偽造オリジンの送信を試み、サーバーがそれを受け入れた場合にのみレポートします。 Cookie チェックは、CSRF の多層防御を低下させる弱い SameSite 属性にもフラグを立てます。