Как это работает¶

CSRF базируется на следующих вещах:

1. Файл cookie CSRF, представляющий собой случайное секретное значение, к которому другие сайты не будут иметь доступа.

   CsrfViewMiddleware отправляет этот файл cookie вместе с ответом всякий раз, когда вызывается django.middleware.csrf.get_token(). Он также может отправить его в других случаях. По соображениям безопасности значение секрета меняется каждый раз, когда пользователь входит в систему.

2. Скрытое поле формы с именем «csrfmiddlewaretoken», присутствующее во всех исходящих формах POST.

   Чтобы защититься от атак BREACH, значение этого поля не является просто секретом. Он шифруется по-разному для каждого ответа с использованием маски. Маска генерируется случайным образом при каждом вызове get_token(), поэтому значение поля формы каждый раз отличается.

   Эту часть выполняет тег шаблона csrf_token.

3. Все HTTP запросы, которые не GET, HEAD, OPTIONS или TRACE, должны содержать CSRF куку, и поле „csrfmiddlewaretoken“ с правильным значением. Иначе пользователь получит 403 ошибку.

   При проверке значения поля csrfmiddlewaretoken сравнивается только секрет, а не полный токен, с секретом в значении файла cookie. Это позволяет использовать постоянно меняющиеся токены. Хотя каждый запрос может использовать свой собственный токен, секрет остается общим для всех.

   Эта проверка выполняется в CsrfViewMiddleware.

4. CsrfViewMiddleware проверяет ``Заголовок Origin`_, если он предоставлен браузером, на соответствие текущему хосту и настройке CSRF_TRUSTED_ORIGINS. Это обеспечивает защиту от междоменных атак.

5. Кроме того, для запросов HTTPS, если заголовок Origin не указан, CsrfViewMiddleware выполняет строгую проверку реферера. Это означает, что даже если субдомен может устанавливать или изменять файлы cookie в вашем домене, он не может заставить пользователя публиковать сообщения в вашем приложении, поскольку этот запрос не будет исходить из вашего собственного домена.

   В дополнение для HTTPS запросов в CsrfViewMiddleware проверяется «referer»(источник запроса). Это необходимо для предотвращения MITM-атаки(Man-In-The-Middle), которая возможна при использовании HTTPS и токена не привязанного к сессии, т.к. клиенты принимают(к сожалению) HTTP заголовок „Set-Cookie“, несмотря на то, что коммуникация с сервером происходит через HTTPS. (Такая проверка не выполняется для HTTP запросов т.к. «Referer» заголовок легко подменить при использовании HTTP.)

   Если установлен параметр CSRF_COOKIE_DOMAIN, референт сравнивается с ним. Вы можете разрешить запросы между поддоменами, включив точку в начале. Например, CSRF_COOKIE_DOMAIN = .example.com разрешит запросы POST от www.example.com и api.example.com. Если параметр не установлен, то реферер должен соответствовать заголовку HTTP Host.

   Чтобы расширить список доступных доменов, кроме текущего хоста и домена кук, используйте CSRF_TRUSTED_ORIGINS.

Такой подход гарантирует, что только формы, отправленные с доверенных доменов, могут передавать POST данные.

Он намеренно игнорирует запросы GET (и другие запросы, которые определены как «безопасные» в RFC 9110 Section 9.2.1). Эти запросы никогда не должны иметь потенциально опасных побочных эффектов, поэтому CSRF-атака с запросом GET должна быть безвредной. RFC 9110 Section 9.2.1 определяет POST, PUT и DELETE как «небезопасные», а все остальные методы также считаются небезопасными для максимальной защиты.

Защита CSRF не может защитить от атак «человек посередине», поэтому используйте HTTPS с HTTP Strict Transport Security. Он также предполагает проверку заголовка HOST и отсутствие уязвимостей межсайтового скриптинга на вашем сайте (поскольку XSS-уязвимости уже позволяют злоумышленнику делать все, что позволяет уязвимость CSRF, и даже хуже).

Ограничения¶

Субдомены на сайте смогут устанавливать файлы cookie на клиенте для всего домена. Установив файл cookie и используя соответствующий токен, субдомены смогут обойти защиту CSRF. Единственный способ избежать этого — убедиться, что субдомены контролируются доверенными пользователями (или, по крайней мере, не могут устанавливать файлы cookie). Обратите внимание, что даже без CSRF существуют другие уязвимости, такие как фиксация сеанса, из-за которых передача поддоменов ненадежным сторонам является плохой идеей, и эти уязвимости невозможно легко исправить с помощью текущих браузеров.

Утилиты¶

Примеры ниже предполагают, чтобы используете представления-функции. Если вы используете представления-классы, обратитесь к этому разделу.

csrf_exempt(view)¶

Этот декоратор позволяет исключить представление из процесса проверки CSRF. Например:

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


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

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)

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)

ensure_csrf_cookie(view)¶

Этот декоратор заставляет представление послать CSRF куку.

Настройки¶

Параметры, которые могут быть использованы для управления поведением CSRF в Django:

• CSRF_COOKIE_AGE

• CSRF_COOKIE_DOMAIN

• CSRF_COOKIE_HTTPONLY

• CSRF_COOKIE_NAME

• CSRF_COOKIE_PATH

• CSRF_COOKIE_NAME

• CSRF_COOKIE_SECURE

• CSRF_FAILURE_VIEW

• CSRF_HEADER_NAME

• CSRF_TRUSTED_ORIGINS

• CSRF_TRUSTED_ORIGINS

Часто задаваемые вопросы¶