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

Как его использовать¶

Чтобы воспользоваться преимуществами защиты от CSRF в ваших представлениях, выполните следующие шаги:

1. По умолчанию промежуточное ПО CSRF активировано в настройках MIDDLEWARE. Если вы переопределите эту настройку, помните, что 'django.middleware.csrf.CsrfViewMiddleware' должно стоять перед любым промежуточным ПО представления, которое предполагает, что CSRF-атаки были обработаны.

   Если вы отключили его, что не рекомендуется, вы можете использовать csrf_protect() на определенных представлениях, которые вы хотите защитить (см. ниже).

2. В любом шаблоне, использующем форму POST, используйте тег csrf_token внутри элемента <form>, если форма предназначена для внутреннего URL, например:

   <form method="post">{% csrf_token %}
   

   Этого не следует делать для POST-форм, нацеленных на внешние URL, поскольку в этом случае произойдет утечка CSRF-токена, что приведет к уязвимости.

3. В соответствующих функциях представления убедитесь, что RequestContext используется для рендеринга ответа, чтобы {% csrf_token %} работал правильно. Если вы используете функцию render(), общие представления или приложения contrib, вы уже защищены, поскольку все они используют RequestContext.

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) {
    // ...
});

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

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

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

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

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

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

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

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

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

   Для защиты от атак BREACH токен - это не просто секрет; к секрету добавляется случайная маска, которая используется для скремблирования.

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

2. Скрытое поле формы с именем „csrfmiddlewaretoken“, присутствующее во всех исходящих POST-формах. Значение этого поля - это, опять же, значение секрета с маской, которая добавляется к нему и используется для скремблирования. Маска регенерируется при каждом вызове 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-уязвимость, и даже намного хуже).

Кэширование¶

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

Однако, если вы используете декораторы кэша на отдельных представлениях, промежуточное ПО CSRF еще не сможет установить заголовок Vary или куки 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):
    ...

Если вы используете представления на основе классов, вы можете обратиться к Decorating class-based views.

Тестирование¶

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

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

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

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

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

Краевые случаи¶

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

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()

Contrib и многократно используемые приложения¶

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

Настройки¶

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

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