しくみ¶

CSRF対策は以下のようなことを基本としています:

1. 他のサイトがアクセスできないランダムな秘密の値である CSRF クッキー。

   CsrfViewMiddleware は django.middleware.csrf.get_token() が呼び出されると、常にこのクッキーをレスポンスと一緒に送信します。その他の場合にも送信できます。セキュリティ上の理由から、secret の値はユーザがログインするたびに変更されます。

2. "csrfmiddlewaretoken" と名付けられた、すべての送信 POST フォームに存在する隠しフォームフィールド。

   BREACH 攻撃から守るために、このフィールドの値は単なる秘密ではありません。マスクを使って、レスポンスごとに異なるスクランブルをかけます。マスクは get_token() を呼び出すたびにランダムに生成されるので、フォームフィールドの値は毎回異なります。

   この動作はテンプレートタグによって行われます。

3. HTTP GET、HEAD、OPTIONS、または TRACE を使用していないすべての受信リクエストについて、CSRF クッキーが存在し、"csrfmiddlewaretoken" フィールドが正しく存在する必要があります。存在しない場合、ユーザは 403 エラーを受け取ります。

   "csrfmiddlewaretoken" フィールドの値を検証するとき、完全なトークンではなくシークレットだけがクッキー値のシークレットと比較されます。これにより、常に変化するトークンを使うことができます。各リクエストは固有のトークンを使うかもしれませんが、シークレットはすべてのリクエストに共通のままです。

   このチェックは CsrfViewMiddleware によって行われます。

4. CsrfViewMiddleware はブラウザから提供された場合、現在のホストと CSRF_TRUSTED_ORIGINS 設定に対して Origin header を検証します。これにより、クロスサブドメイン攻撃から保護されます。

5. さらに、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 するために使用できるようになります。

GET リクエスト（および RFC 9110#section-9.2.1 によって「安全」と定義されている他のリクエスト）を意図的に無視します。これらのリクエストは決して潜在的に危険な副作用を持つべきではなく、したがって GET リクエストを使用した CSRF 攻撃は無害であるべきです。 RFC 9110#section-9.2.1 は POST、PUT、DELETE を「安全でない」と定義し、最大限の保護のためには、他のすべてのメソッドも安全でないとみなされます。

CSRF保護は中間者攻撃に対して保護することはできませんので、HTTPS を HTTP Strict Transport Security と共に使用してください。また、HOSTヘッダーの検証 が行われていること、およびサイト上に クロスサイトスクリプティングの脆弱性 が存在しないことを前提としています（なぜなら、XSSの脆弱性は既に攻撃者がCSRFの脆弱性を利用して行えること、そしてそれ以上のことを可能にするからです）。

制限事項¶

サイト内のサブドメインは、ドメイン全体のクライアントにクッキーを設定できます。クッキーを設定し、対応するトークンを使うことで、サブドメインは CSRF 防御を回避できます。これを避ける唯一の方法は、サブドメインが信頼されたユーザによって管理される（あるいは、少なくともクッキーを設定できない）ようにすることです。CSRF がなくても、セッションの固定化など、サブドメインを信頼できない相手に与えることを悪用する脆弱性は他にもあり、これらの脆弱性は現在のブラウザでは簡単に修正できないことに注意してください。

ユーティリティ¶

以下の例では、関数ベースのビューを使っていることを想定しています。クラスベースのビューを使っている場合は、Decorating class-based views を参照してください。

csrf_exempt(view)¶

このデコレータは、ビューがミドルウェアによる保護の対象外であることを示します。例:

from django.http import HttpResponse
from django.views.decorators.csrf import csrf_exempt


@csrf_exempt
def my_view(request):
    return HttpResponse("Hello world")

Changed in Django 5.0:

非同期ビュー関数のラップをサポートしました。

csrf_protect(view)¶

ビューに対する CsrfViewMiddleware の保護を提供するデコレータです。

使い方は以下の通りです:

from django.shortcuts import render
from django.views.decorators.csrf import csrf_protect


@csrf_protect
def my_view(request):
    c = {}
    # ...
    return render(request, "a_template.html", c)

Changed in Django 5.0:

非同期ビュー関数のラップをサポートしました。

requires_csrf_token(view)¶

通常 csrf_token テンプレートタグは CsrfViewMiddleware.process_view または csrf_protect のような等価なものが実行されていないと動作しません。ビューデコレータ requires_csrf_token を使用すると、テンプレートタグを確実に動作させることができます。このデコレータは csrf_protect と同様に動作しますが、リクエストを拒否することはありません。

実装例:

from django.shortcuts import render
from django.views.decorators.csrf import requires_csrf_token


@requires_csrf_token
def my_view(request):
    c = {}
    # ...
    return render(request, "a_template.html", c)

Changed in Django 5.0:

非同期ビュー関数のラップをサポートしました。

ensure_csrf_cookie(view)¶

このデコレータはビューに強制的に CSRF クッキーを送信させます。

Changed in Django 5.0:

非同期ビュー関数のラップをサポートしました。

設定¶

Django の CSRF 動作を制御するための、多くの設定があります:

• CSRF_COOKIE_AGE
• CSRF_COOKIE_DOMAIN
• CSRF_COOKIE_HTTPONLY
• CSRF_COOKIE_NAME
• CSRF_COOKIE_PATH
• CSRF_COOKIE_SAMESITE
• CSRF_COOKIE_SECURE
• CSRF_FAILURE_VIEW
• CSRF_HEADER_NAME
• CSRF_TRUSTED_ORIGINS
• CSRF_USE_SESSIONS

よくある質問¶