Как использовать защиту Django от CSRF

Защита от CSRF при использовании AJAX

Описанный выше метод можно использовать для AJAX-запросов POST, но он имеет некоторые неудобства: нужно не забывать передавать токен CSRF в данных POST для каждого запроса POST. Поэтому существует альтернативный метод: для каждого XMLHttpRequest устанавливайте пользовательский заголовок X-CSRFToken (как указано в настройке CSRF_HEADER_NAME) со значением токена CSRF. Часто это проще, поскольку многие JavaScript-фреймворки предоставляют хуки, позволяющие устанавливать заголовки для каждого запроса.

Сначала необходимо получить токен CSRF. Способ зависит от того, включены ли настройки CSRF_USE_SESSIONS и CSRF_COOKIE_HTTPONLY.

function getCookie(name) {
    let cookieValue = null;
    if (document.cookie && document.cookie !== '') {
        const cookies = document.cookie.split(';');
        for (let i = 0; i < cookies.length; i++) {
            const cookie = cookies[i].trim();
            // Does this cookie string begin with the name we want?
            if (cookie.substring(0, name.length + 1) === (name + '=')) {
                cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
                break;
            }
        }
    }
    return cookieValue;
}
const csrftoken = getCookie('csrftoken');

const csrftoken = Cookies.get('csrftoken');

{% csrf_token %}
<script>
const csrftoken = document.querySelector('[name=csrfmiddlewaretoken]').value;
</script>

const request = new Request(
    /* URL */,
    {
        method: 'POST',
        headers: {'X-CSRFToken': csrftoken},
        mode: 'same-origin' // Do not send CSRF token to another domain.
    }
);
fetch(request).then(function(response) {
    // ...
});

Использование защиты от CSRF в шаблонах Jinja2

Бэкенд шаблонов Django Jinja2 добавляет {{ csrf_input }} в контекст всех шаблонов. Это эквивалентно {% csrf_token %} в языке шаблонов Django. Например:

<form method="post">{{ csrf_input }}

Использование декоратора

Вместо того чтобы повсеместно добавлять CsrfViewMiddleware для защиты, можно использовать декоратор csrf_protect(), обладающий точно такой же функциональностью, для отдельных представлений, которым нужна защита. Его необходимо применять как к представлениям, добавляющим токен CSRF в вывод, так и к тем, которые принимают данные формы POST. (Часто это одна и та же функция представления, но не всегда.)

Использовать только декоратор не рекомендуется, поскольку, если вы забудете его применить, возникнет уязвимость. Стратегия «ремень и подтяжки» с использованием обоих вариантов вполне подходит и создаёт минимальные дополнительные затраты.

Обработка отклонённых запросов

По умолчанию, если входящий запрос не проходит проверки, выполняемые CsrfViewMiddleware, пользователю отправляется ответ «403 Forbidden». Обычно это происходит только при настоящей атаке Cross Site Request Forgery или если из-за ошибки программирования токен CSRF не был включён в форму POST.

Однако страница ошибки не слишком дружелюбна, поэтому вы можете создать собственное представление для обработки этой ситуации. Для этого задайте настройку CSRF_FAILURE_VIEW.

Сбои проверки CSRF регистрируются как предупреждения в журнале django.security.csrf.

Использование защиты от CSRF с кэшированием

Если шаблон использует тег шаблона csrf_token (или функция get_token вызывается другим способом), CsrfViewMiddleware добавит в ответ cookie и заголовок Vary: Cookie. Это означает, что промежуточное ПО будет корректно работать с промежуточным ПО кэширования, если оно используется согласно инструкциям (UpdateCacheMiddleware должно располагаться перед всем остальным промежуточным ПО).

Однако если вы используете декораторы кэширования для отдельных представлений, промежуточное ПО CSRF ещё не успеет установить заголовок Vary или cookie CSRF, и ответ будет кэширован без них. В этом случае для всех представлений, в которые необходимо вставить токен CSRF, сначала следует использовать декоратор django.views.decorators.csrf.csrf_protect():

from django.views.decorators.cache import cache_page
from django.views.decorators.csrf import csrf_protect


@cache_page(60 * 15)
@csrf_protect
def my_view(request): ...

Если вы используете представления на основе классов, обратитесь к разделу Декорирование представлений на основе классов.

Тестирование и защита от CSRF

CsrfViewMiddleware обычно существенно затрудняет тестирование функций представлений из-за необходимости передавать токен CSRF с каждым запросом POST. Поэтому HTTP-клиент Django для тестов был изменён: он устанавливает для запросов флаг, который ослабляет проверки промежуточного ПО и декоратора csrf_protect, так что они больше не отклоняют запросы. Во всех остальных отношениях (например, при отправке cookie) они работают так же.

Если по какой-либо причине вы хотите, чтобы тестовый клиент выполнял проверки CSRF, можно создать экземпляр тестового клиента, который принудительно выполняет эти проверки:

>>> from django.test import Client
>>> csrf_client = Client(enforce_csrf_checks=True)

Особые случаи

Некоторые представления могут иметь необычные требования, из-за которых они не соответствуют описанному здесь стандартному шаблону. В таких ситуациях могут быть полезны различные средства. Сценарии их применения описаны в следующем разделе.

from django.views.decorators.csrf import csrf_exempt, csrf_protect


@csrf_exempt
def my_view(request):
    @csrf_protect
    def protected_path(request):
        do_something()

    if some_condition():
        return protected_path(request)
    else:
        do_something_else()

Защита от CSRF в повторно используемых приложениях

Поскольку разработчик может отключить CsrfViewMiddleware, все соответствующие представления в приложениях contrib используют декоратор csrf_protect, чтобы защитить эти приложения от CSRF. Разработчикам других повторно используемых приложений, которым нужны такие же гарантии, рекомендуется также использовать декоратор csrf_protect для своих представлений.