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

Использование защиты от 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. (Это часто одна и та же функция представления, но не всегда).

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

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

По умолчанию пользователю отправляется ответ «403 Forbidden», если входящий запрос не проходит проверки, выполняемые CsrfViewMiddleware. Это обычно должно наблюдаться только тогда, когда существует подлинная межсайтовая подделка запроса или когда из-за ошибки программирования маркер 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, вы можете создать экземпляр тестового клиента, который применяет проверки 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 для своих представлений.