Защита от подделки межсайтовых запросов¶

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

Защита от CSRF основана на следующих моментах:

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

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

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

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

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

3. Для всех входящих запросов, не использующих HTTP GET, HEAD, OPTIONS или TRACE, должен присутствовать CSRF cookie, а поле „csrfmiddlewaretoken“ должно быть настоящим и правильным. Если это не так, пользователь получит ошибку 403.

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

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

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

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

   Это также устраняет атаку «человек посередине», которая возможна в 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.

   Расширить список принимаемых ссылок за пределы текущего хоста или домена cookie можно с помощью параметра CSRF_TRUSTED_ORIGINS.

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

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

Защита CSRF не может защитить от атак типа «человек посередине», поэтому используйте HTTPS с Строгая транспортная безопасность HTTP. Это также предполагает validation of the HOST header и отсутствие cross-site scripting vulnerabilities на вашем сайте (потому что XSS-уязвимости уже позволяют злоумышленнику делать все, что позволяет CSRF-уязвимость, и даже намного хуже).

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

Поддомены в рамках сайта смогут устанавливать cookie на клиенте для всего домена. Устанавливая куки и используя соответствующий токен, поддомены смогут обойти защиту CSRF. Единственный способ избежать этого - убедиться, что поддомены контролируются доверенными пользователями (или, по крайней мере, не могут устанавливать cookies). Обратите внимание, что даже без 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')

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 cookie.

Настройки¶

Для управления поведением 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

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