CSRF ミドルウェアとテンプレートタグは、簡単に扱える Cross Site Request Forgeries 対策を提供しています。このタイプの攻撃は、訪問者のログイン情報を悪用してあなたのサイトに何らかの操作を行うことを目的とした、リンクやフォームボタン、 JavaScript を設置した悪意のあるウェブサイトによって行われます。また、関連する攻撃として、ユーザーを騙して別のユーザー権限でログインさせる 'ログイン CSRF' と呼ばれる攻撃もありますが、これも対策に含まれます。
\nCSRF 攻撃に対する第一の防御は、 GET リクエスト (および RFC 9110 Section 9.2.1 で定義された ‘安全な’ メソッド) から副作用を取り除くというものです。そして、 POST、PUT、DELETE のような、’安全でない’ メソッドによるリクエストについては、 Django の CSRF 保護を利用する で説明されている手順で保護できます。
\nCSRF対策は以下のようなことを基本としています:
\n他のサイトがアクセスできないランダムな秘密の値である CSRF クッキー。
\nCsrfViewMiddleware は django.middleware.csrf.get_token() が呼び出されると、常にこのクッキーをレスポンスと一緒に送信します。その他の場合にも送信できます。セキュリティ上の理由から、secret の値はユーザがログインするたびに変更されます。
"csrfmiddlewaretoken" と名付けられた、すべての送信 POST フォームに存在する隠しフォームフィールド。
\nBREACH 攻撃から守るために、このフィールドの値は単なる秘密ではありません。マスクを使って、レスポンスごとに異なるスクランブルをかけます。マスクは get_token() を呼び出すたびにランダムに生成されるので、フォームフィールドの値は毎回異なります。
この部分は、csrf_token テンプレートタグによって行われます。
HTTP GET、HEAD、OPTIONS、または TRACE を使用していないすべての受信リクエストについて、CSRF クッキーが存在し、"csrfmiddlewaretoken" フィールドが正しく存在する必要があります。存在しない場合、ユーザは 403 エラーを受け取ります。
\n"csrfmiddlewaretoken" フィールドの値を検証するとき、完全なトークンではなくシークレットだけがクッキー値のシークレットと比較されます。これにより、常に変化するトークンを使うことができます。各リクエストは固有のトークンを使うかもしれませんが、シークレットはすべてのリクエストに共通のままです。
\nこのチェックは CsrfViewMiddleware によって行われます。
CsrfViewMiddleware はブラウザから提供された場合、現在のホストと CSRF_TRUSTED_ORIGINS 設定に対して Origin header を検証します。これにより、クロスサブドメイン攻撃から保護されます。
さらに、HTTPS リクエストの場合、Origin ヘッダーが提供されない場合には、CsrfViewMiddleware は厳密なリファラチェックを実行します。これは、サブドメインがあなたのドメインに対してクッキーを設定または変更できるとしても、そのリクエストがあなた自身の正確なドメインから来ない限り、ユーザーがあなたのアプリケーションに対して投稿を強制することはできないことを意味します。
これはまた、セッションに依存しない秘密を使用するときに HTTPS で可能な中間者攻撃 (man-in-the-middle attack) に対処するためでもあります。 HTTP の Set-Cookie ヘッダは (残念ながら) クライアントが HTTPS でサイトと通信しているときでも受け付けられます。 (Referer ヘッダーの存在が HTTP 下では十分に信頼できないため、HTTP リクエストに対してはリファラチェックは行われません。)
もし CSRF_COOKIE_DOMAIN 設定が設定されていれば、リファラはその設定と比較されます。先頭のドットを指定することで、クロスサブドメインリクエストを許可できます。たとえば、CSRF_COOKIE_DOMAIN = '.example.com' は www.example.com と api.example.com からの POST リクエストを許可します。この設定が設定されていない場合、referer は HTTP の Host ヘッダと一致しなければなりません。
CSRF_TRUSTED_ORIGINS 設定により、現在のホストやクッキーのドメインを超えてリファラを拡張できます。
これにより、信頼できるドメインから送信されたフォームだけが、データを POST するために使用できるようになります。
\nGET リクエスト（および RFC 9110 Section 9.2.1 によって「安全」と定義されている他のリクエスト）を意図的に無視します。これらのリクエストは決して潜在的に危険な副作用を持つべきではなく、したがって GET リクエストを使用した CSRF 攻撃は無害であるべきです。 RFC 9110 Section 9.2.1 は POST、PUT、DELETE を「安全でない」と定義し、最大限の保護のためには、他のすべてのメソッドも安全でないとみなされます。
\nCSRF保護は中間者攻撃に対して保護することはできませんので、HTTPS を HTTP Strict Transport Security と共に使用してください。また、HOSTヘッダーの検証 が行われていること、およびサイト上に クロスサイトスクリプティングの脆弱性 が存在しないことを前提としています（なぜなら、XSSの脆弱性は既に攻撃者がCSRFの脆弱性を利用して行えること、そしてそれ以上のことを可能にするからです）。
\n\nサイト内のサブドメインは、ドメイン全体のクライアントにクッキーを設定できます。クッキーを設定し、対応するトークンを使うことで、サブドメインは CSRF 防御を回避できます。これを避ける唯一の方法は、サブドメインが信頼されたユーザによって管理される（あるいは、少なくともクッキーを設定できない）ようにすることです。CSRF がなくても、セッションの固定化など、サブドメインを信頼できない相手に与えることを悪用する脆弱性は他にもあり、これらの脆弱性は現在のブラウザでは簡単に修正できないことに注意してください。
\n以下の例では、関数ベースのビューを使っていることを想定しています。クラスベースのビューを使っている場合は、Decorating class-based views を参照してください。
\nこのデコレータは、ビューがミドルウェアによる保護の対象外であることを示します。例:
\nfrom django.http import HttpResponse\nfrom django.views.decorators.csrf import csrf_exempt\n\n\n@csrf_exempt\ndef my_view(request):\n return HttpResponse("Hello world")\nビューに対する CsrfViewMiddleware の保護を提供するデコレータです。
使い方は以下の通りです:
\nfrom django.shortcuts import render\nfrom django.views.decorators.csrf import csrf_protect\n\n\n@csrf_protect\ndef my_view(request):\n c = {}\n # ...\n return render(request, "a_template.html", c)\n通常 csrf_token テンプレートタグは CsrfViewMiddleware.process_view または csrf_protect のような等価なものが実行されていないと動作しません。ビューデコレータ requires_csrf_token を使用すると、テンプレートタグを確実に動作させることができます。このデコレータは csrf_protect と同様に動作しますが、リクエストを拒否することはありません。
実装例:
\nfrom django.shortcuts import render\nfrom django.views.decorators.csrf import requires_csrf_token\n\n\n@requires_csrf_token\ndef my_view(request):\n c = {}\n # ...\n return render(request, "a_template.html", c)\nこのデコレータはビューに強制的に CSRF クッキーを送信させます。
\n\nDjango の CSRF 動作を制御するための、多くの設定があります:
\n\nいいえ、これは設計によるものです。CSRF 防御をセッションにリンクしないことで、 pastebin のような、セッションを持たない匿名ユーザからの投稿を許可するサイトで保護を使用できます。
\nCSRF トークンをユーザのセッションに保存したい場合は、 CSRF_USE_SESSIONS 設定を使用します。
セキュリティ上の理由から、CSRF トークンはユーザがログインするたびにローテーションされます。ログイン前にフォームが生成されたページは、古くて無効な CSRF トークンを持つことになり、再読み込みが必要になります。これは、ユーザがログイン後に戻るボタンを使用した場合や、別のブラウザのタブでログインした場合に発生することがあります。
\n