Использование CSRF защиты с AJAX¶

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

Для начала, нужно получить CSRF токен. Как это сделать, зависит от того, установлены ли настройки CSRF_USE_SESSIONS and 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¶

Бэкенд шаблона Jinja2 добавляет {{ csrf_input }} в контекст всех шаблонов, что является эквивалентом использованию {% csrf_token %} в шаблоне. К примеру:

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

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

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

Использование самого по себе декоратора не рекомендуется, потому что вы можете забыть его применить, что создаст угрозу безопасности

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

По-умолчанию, если запрос отклоняется после проверки CsrfViewMiddleware, пользователь получает ответ „403 Forbidden“. Обычно это происходит при реальной CSRF атаке или когда в результате ошибки CSRF токен не был добавлен в POST форму.

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

Логгером django.security.csrf CSRF ошибки записываются как предупреждения.

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

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

Однако, если вы ставите декораторы на конкретные функции представлений, CSRF middleware не сможет установить HTTP заголовок Vary или куки CSRF, и ответ сервера будет закэширован и без заголовка, и без куки. В этом случае, на таких функциях вам также необходимо устанавливать декоратор func: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 может создать проблемы при тестировании представлений (views), из-за необходимости отправлять CSRF токен с каждым POST запросом. По этой причине HTTP клиент Django для тестов был модифицирован таким образом, что он устанавливает определенный флаг в запросах и csrf_protect декораторе, чтобы они не отменяли такие запросы. Во всех остальных отношениях (к примеру, отправке кукис и т.д.), они будут работать так же, как и раньше.

Если, по какой-либо причине, вы хотите, чтобы тестовый клиент выполнял 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, все соответствующие представления в приложениях contriиспользуют декоратор csrf_protect для обеспечения безопасности этих приложений от CSRF. Разработчикам других приложений, которые хотят получить те же гарантии, также рекомендуется использовать декоратор csrf_protect в своих представлениях.