Как реализовать CSRF-защиту
CSRF — или Межсайтовая подделка запроса — это метод, которым недобросовестный пользователь пытается заставить ваших пользователей не зная об этом, отправлять данные, которые они не собирались отправлять.
Защита от CSRF работает путём добавления ввашу форму скрытого поля, которое содержит значение, которое знаете только вы и ваш пользователь. Это гарантирует, что пользователь — а не какая-то другая сущность — отправляет данные.
Перед использованием CSRF-защиты, установите её в вашем проекте:
$ composer require symfony/security-csrf
Затем, включитте/выключите CSRF-защиту с помощью опции csrf_protection (см. справочник конфигурации CSRF , чтобы узнать больше):
1 2 3 4
# config/packages/framework.yaml framework: # . csrf_protection: ~
1 2 3 4 5 6 7 8 9 10 11 12 13 14
container xmlns="http://symfony.com/schema/dic/services" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:framework="http://symfony.com/schema/dic/symfony" xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd http://symfony.com/schema/dic/symfony http://symfony.com/schema/dic/symfony/symfony-1.0.xsd"> framework:config> framework:csrf-protection enabled="true" /> framework:config> container>
1 2 3 4 5 6 7 8
// config/packages/framework.php use Symfony\Config\FrameworkConfig; return static function (FrameworkConfig $framework) < $framework->csrfProtection() ->enabled(true) ; >;
Токены, используемые для CSRF-защиты, должны быть разными для каждого пользователя, и они хранятся в сессии. Поэтому сессия начинается автоматически, как только вы отображаете форму с CSRF-защитой.
Более того, это означает, что вы не можете полностью кешировать страницы, которые имеют формы с защитой от CSRF. Как вариант, вы можете:
- Встроить форму внутрь некешируемого фрагмента ESI и кешировать остаток содержания страницы;
- Кешировать всю страницу и загрузить форму через некешируемый запрос AJAX;
- Кешировать всю страницу и использовать hinclude.js для загрузки CSRF-токена с некешируемым запросом AJAX, и заменить значение поля формы им.
CSRF-защита в формах Symfony
Формы, созданные с помощью компонента Symfony Форма включают в себя токены CSRF по умолчанию, и Symfony проверяет их автоматически, так что вам не нужно ничего делать, чтобы быть защищёнными от CSRF атак.
По умолчанию, Symfony добавляет CSRF токен в скрытое поле под названием _token , но это можно настраивать от формы к форме:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
// src/Form/TaskType.php namespace App\Form; // . use App\Entity\Task; use Symfony\Component\OptionsResolver\OptionsResolver; class TaskType extends AbstractType < // . public function configureOptions(OptionsResolver $resolver): void < $resolver->setDefaults([ 'data_class' => Task::class, // включить/выключить защиту от CSRF для этой формы 'csrf_protection' => true, // имя скрытого HTML поля, хранящего токен 'csrf_field_name' => '_token', // произвольная строка, использовання для генерирования значения токена, // использование другой строки для каждой формы усиливает её безопасность 'csrf_token_id' => 'task_item', ]); > // . >
Вы также можете настроить отображение поля формы CSRF, создав пользовательскую тему формы и используя csrf_token в качестве префикса поля (например, определить . , чтобы настроить все содержание поля формы).
CSRF-защита в формах входа в систему
См. , чтобы увидеть форму входа в систему, которая защищена от CSRF-атак. Вы также можете сконфигурировать CSRF-защиту для действия выхода из системы .
Генерирование и проверка CSRF-токенов вручную
Хотя Формы Symfony предоставляют автоматическую CSRF-защиту по умолчанию, вам может понадобиться сгенерировать и проверить CSRF-токены вручную, например, при использовании обычных HTML-форм, не управляемыъ компонентом Symfony Формы.
Рассмотрите HTML-форму, созданную для позволения удаления объектов. Для начала, используйте функцию Twig csrf_token(), чтобы сгенерировать CSRF-токен в шаблоне и сохранить его в скрытом поле формы:
1 2 3 4 5 6
form action=") >>" method="post"> input type="hidden" name="token" value=">"/> button type="submit">Delete item button> form>
Затем, получите значение CSRF-токена в действии контроллера и используйте метод isCsrfTokenValid() чтобы проверить его валидность:
1 2 3 4 5 6 7 8 9 10 11 12 13
use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\Response; // . public function delete(Request $request): Response < $submittedToken = $request->request->get('token'); // 'delete-item' это то же значение, что используется в шаблоне для генерирования токена if ($this->isCsrfTokenValid('delete-item', $submittedToken)) < // . сделайте что-то, вроде удаления объекта > >
CSRF-токены и сжатие атак по сторонним каналам
BREACH и CRIME — это эксплойты безопасности против HTTPS при использовании сжатия HTTP. Хакеры могут использовать информацию, упущенную во время сжатия, чтобы восстановить целевые части открытого текста. Чтобы ослабить эти атаки, и предупредить хакера от укгадывания CSRF-токенов, к началу токена добавляется рандомная маска, которая используется для его перемешивания.
Рандомизация токенов была представлена в Symfony 5.3
Что такое CSRF? Значение термина CSRF
CSRF (Сross Site Request Forgery — подделка межсайтовых запросов) Так же известен как XSRF. Данный вид атак на посетителей интернет-сайтов использует недостатки HTTP протокола. Если жертва зайдет на сайт, который специально был создан злоумышленником, то от ее лица тайно отправится запрос на сторонний сервер (например сервер электронных платежей), осуществляющий некую вредоносную операцию (перевод денег на счет взломщика). Для успеха данной атаки, жертва должна быть авторизована на сервере, на который отправится запрос. Сам запрос не должен требовать подтверждения со стороны пользователя.
Вопреки бытующему мнения, данный тип атак появился весьма давно. Теоретические рассуждения по этому вопросу появились еще в 1988 году, а первые уязвимости обнаружили в 2000 году.
Одним из применений CSRF является эксплуатация пассивных XSS, обнаруженных на другом сервере. Возможны так же спам-рассылки от лица жертвы, изменение настроек учетной записи на другом сайте.
Самым простым способом защиты от подобного типа атак является механизм, когда сайт требует подтверждения почти всех действий пользователя.
Другим способом защиты является механизм, когда с сессией пользователя ассоциируется секретный ключ, необходимый для выполнения POST-запросов. Ключ посылается пользователем внутри каждого запроса, при выполнении различных действий, а сервер проверяет данный ключ. Плюс механизма в отсутствии необходимости осуществлять парсинг поля HTTP_REFERER, а следовательно отпадает необходимость учета многих нюансов возможных вариантов отсутствия или присутствия различных элементов этого поля.
Помогло? Делись!
Реклама:
Представляем
систему управления сайтами
NetCat
CMS NetCat — профессиональная коммерческая система управления Интернет-сайтами, один из лидеров на российском рынке веб-разработок.
Наша компания является сертифицированным партнером и рекомендуемым разработчиком сайтов на NetCat во Владивостоке.
В настоящее время большинство новых сайтов мы создаем на основе ее программной платформы.
Сообщения об ошибке CSRF токена
Если вы видите сообщение об ошибке CSRF токена при входе в аккаунт Todoist, ничего страшного. Простые решения проблемы описаны ниже.
CSRF токен недействителен или отсутствует
Это сообщение означает, что вашему браузеру не удалось создать защищённые файлы куки или получить к ним доступ, чтобы авторизовать вход в вашу учетную запись. Причиной этого могут быть плагины для блокировки рекламы и скриптов, а также настройки браузера, если они не разрешают настройку куки.
Чтобы решить проблему, следуйте этой инструкции:
Google Chrome
- Откройте Настройки Chrome.
- В разделе Конфиденциальность и безопасность выберите Файлы cookie и другие данные сайтов.
- Прокрутите вниз до Сайты, которые всегда могут использовать файлы cookie и нажмите Добавить.
- Скопируйте и вставьте «[*.]todoist.com», нажмите Добавить.
- Затем скопируйте и вставьте «[*.]cloudfront.net», нажмите Добавить.
- Нажмите Все файлы cookie и данные сайта, введите в поле поиска todoist и удалите все записи, связанные с Todoist.
- Перезагрузите Chrome и войдите в аккаунт Todoist.
Firefox
- Откройте Настройки Firefox.
- Слева выберите раздел Приватность и Защита.
- В разделе Куки и данные сайтов нажмите на кнопку Управление исключениями.
- Скопируйте и вставьте «https://todoist.com», нажмите Добавить.
- Затем скопируйте и вставьте «https://cloudfront.net», нажмитеДобавить.
Safari
- Откройте настройки Safari из выпадающего меню в панели навигации, либо нажав Cmd + , (⌘,).
- Нажмите на вкладку «Конфиденциальность» и убедитесь, что для пункта «Файлы cookie и данные веб-сайтов» не выбрано «Блокировать все файлы cookie» .
- Нажмите Управление данными веб-сайтов, чтобы увидеть данные всех веб-сайтов, которые хранятся локально.
- Найдите «Todoist» и удалите все записи, связанные с Todoist.
- Перезагрузите Safari и войдите в аккаунт Todoist.
CSRF токены не совпадают
Это сообщение об ошибке возникает из-за расширений для защиты конфиденциальности. Если вы используете такие расширения, как Ghostery или Privacy Badger, добавьте todoist.com в список доверенных сайтов.
Защита от «подделки межсайтовых запросов» (CSRF) ¶
Промежуточное ПО CSRF и теги шаблонов упрощают защиту от атак с подделкой межсайтовых запросов . Этот тип атаки происходит, когда вредоносный веб-сайт содержит ссылку, кнопку формы или фрагмент кода JavaScript, который предназначен для выполнения действия на вашем веб-сайте с использованием учетных данных авторизованного пользователя, который посещает вредоносный сайт в своем браузере. Также рассматривается родственный тип атаки: «CSRF login», когда атакующий сайт обманывает браузер пользователя, подключаясь к сайту с чужими учетными данными.
Первая линия защиты от атак CSRF — гарантировать, что запросы GET (и другие «безопасные» методы, как определено RFC 7231 # section-4.2.1 ) не имеют побочных эффектов. Вызовы «небезопасными» методами, такими как POST, PUT и DELETE, затем можно защитить, выполнив следующие действия.
Как пользоваться ¶
Чтобы воспользоваться преимуществами защиты CSRF в представлениях, сделайте следующее:
- По умолчанию промежуточное ПО CSRF включено в настройках MIDDLEWARE . Если вы переопределите этот параметр, помните, что это ‘django.middleware.csrf.CsrfViewMiddleware’ должно происходить до того, как промежуточное ПО, которое полагается на CSRF-атаки, уже было отражено. Если вы отключите его, что не рекомендуется, вы можете использовать его csrf_protect() в некоторых представлениях, которые хотите защитить (см. Ниже).
- В любом шаблоне, который использует форму POST, используйте тег шаблона csrf_token внутри тега HTML, если форма ссылается на внутренний URL-адрес, например:
form method="post"> csrf_token %>
AJAX ¶
Несмотря на то, что вышеуказанный метод может использоваться для запросов AJAX POST, у него есть несколько недостатков: не забудьте передать токен CSRF вместе с данными POST в каждом запросе POST. По этой причине существует другой метод: для каждого XMLHttpRequest определите элемент заголовка X-CSRFToken (как указано в настройке CSRF_HEADER_NAME ) с тем же значением, что и токен CSRF. Часто это проще, потому что многие библиотеки JavaScript предоставляют точки расширения, которые позволяют добавлять элементы заголовка для каждого запроса.
Сначала необходимо получить токен CSRF. Способ сделать это зависит от того CSRF_USE_SESSIONS , включены ли настройки и CSRF_COOKIE_HTTPONLY .
Приобретение если CSRF_USE_SESSIONS и CSRF_COOKIE_HTTPONLY стоит знак False ¶
Рекомендуемым источником для токена является файл cookie csrftoken , который будет присутствовать, если у вас включена защита CSRF для вашего представления, как показано выше.
Файл cookie CSRF имеет имя csrftoken по умолчанию, но вы можете изменить это имя в настройках CSRF_COOKIE_NAME .
Получить токен можно так:
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');
Приведенный выше код можно упростить, заменив библиотеку Cookie JavaScript getCookie :
const csrftoken = Cookies.get('csrftoken');
Маркер CSRF также присутствует в DOM, но только если он явно включен с помощью тега csrf_token в шаблоне. Файл cookie будет содержать стандартный токен; он CsrfViewMiddleware предпочтет cookie токену DOM. В любом случае вы гарантированно получите cookie, если токен присутствует в DOM, поэтому лучше использовать cookie!
Если представление не использует шаблон, содержащий тег csrf_token , Django может не установить файл cookie CSRF. Такая ситуация часто возникает в случаях, когда формы динамически добавляются на страницу. Чтобы решить эту проблему, Django предоставляет вид декоратора , который заставляет использовать куки: ensure_csrf_cookie() .
Приобретение токена, если CSRF_USE_SESSIONS или CSRF_COOKIE_HTTPONLY стоит True ¶
Если вы включили CSRF_USE_SESSIONS или CSRF_COOKIE_HTTPONLY , вы должны включить токен CSRF в HTML-код и прочитать токен в DOM в JavaScript:
csrf_token %> script> const csrftoken = document.querySelector('[name=csrfmiddlewaretoken]').value; script>
Установка токена для запроса AJAX ¶
Наконец, вам нужно установить заголовок для вашего запроса AJAX. Используя API fetch () :
const request = new Request( /* URL */, headers: 'X-CSRFToken': csrftoken>> ); fetch(request, method: 'POST', mode: 'same-origin' // Do not send CSRF token to another domain. >).then(function(response) // . >);
Использование CSRF в шаблонах Jinja2 ¶
Jinja2 Механизм шаблонов Django добавляет контекст всех шаблонов, что эквивалентно языку шаблонов Django. Например : >
form method="post"> <csrf_input >>
Метод декоратора ¶
Вместо того, чтобы добавлять CsrfViewMiddleware в качестве общей защиты, вы можете использовать декоратор csrf_protect , который предлагает точно такую же функциональность, для конкретных представлений, которые нуждаются в защите. Этот декоратор следует использовать как в представлениях, которые включают в себя токен CSRF, так и в представлениях, которые принимают данные формы POST. (Часто это одна и та же функция просмотра, но не всегда).
Не рекомендуется прибегать к использованию одного декоратора , потому что, если вы забудете его использовать, у вас будет дыра в безопасности. Стратегия «пояс и подтяжки» с использованием того и другого хороша и приведет лишь к минимальной перегрузке.
Декоратор, обеспечивающий защиту представления, подобную промежуточному программному обеспечению 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)
Если вы используете представления на основе классов, вы можете обратиться к разделу «Украшение представлений на основе классов» .
Отклоненные запросы ¶
По умолчанию пользователю возвращается ответ «403 Forbidden», если входящий запрос не удовлетворяет проверкам, выполненным пользователем CsrfViewMiddleware . Как правило, это должно появляться только в том случае, если это настоящая атака «Подделка межсайтового запроса» или когда из-за ошибки программирования токен CSRF не был включен в форму. типа POST.
Однако страница с ошибкой не очень приятная, поэтому вы можете предоставить собственное представление для решения этой проблемы. Для этого определите настройку CSRF_FAILURE_VIEW .
Сбои CSRF регистрируются как предупреждения в журнале django.security.csrf .
Операция ¶
Защита CSRF основана на следующем:
- Файл cookie CSRF, основанный на случайном секретном значении, к которому другие сайты не будут иметь доступа. Этот файл cookie создается промежуточным программным обеспечением CsrfViewMiddleware . Он отправляется с каждым вызванным ответом django.middleware.csrf.get_token() (функция, используемая внутри для получения токена CSRF), если он еще не был определен для запроса. Для защиты от атак BREACH токен — это не просто секрет; к секрету добавляется случайная маска, которая используется для его шифрования. По соображениям безопасности секретное значение изменяется каждый раз, когда пользователь входит в систему.
- Скрытое поле формы с именем «csrfmiddlewaretoken» присутствует во всех исходящих формах POST. Значение этого поля, опять же, является значением секрета с маской, которая добавляется к нему и используется для его шифрования. Маска регенерируется при каждом вызове, get_token() поэтому значение поля формы изменяется в каждом таком ответе. Это действие выполняется тегом шаблона.
- Для всех входящих запросов, которые не используют методы HTTP GET, HEAD, OPTIONS или TRACE, должен присутствовать файл cookie CSRF, а поле «csrfmiddlewaretoken» должно присутствовать и быть правильным. В противном случае пользователь получит ошибку 403. При проверке значения поля csrfmiddlewaretoken только секретное значение, а не полный токен, сравнивается с секретным значением содержимого cookie. Это позволяет использовать постоянно меняющиеся токены. Хотя каждый запрос может использовать свой токен, секретное значение остается общим для всех. Эта проверка выполняется промежуточным программным обеспечением CsrfViewMiddleware .
- Кроме того, для запросов HTTPS строгий контроль реферера выполняется CsrfViewMiddleware . Это означает, что даже если субдомен может устанавливать или изменять файлы cookie для вашего домена, он не может заставить пользователя отправлять данные в ваше приложение, потому что этот запрос не будет исходить из вашего точного домена. Это также защищает от атаки «Man-In-The-Middle», которая возможна по протоколу HTTPS при использовании независимого от сеанса секретного значения, поскольку заголовки HTTP Set-Cookie (к сожалению) принимаются клиенты, даже когда они общаются с сайтом по HTTPS. (Проверка реферера не выполняется для HTTP-запросов, потому что наличие заголовка Referer недостаточно надежно для HTTP.) Если настройка CSRF_COOKIE_DOMAIN определена, референт сравнивается с ней. Этот параметр учитывает поддомены. Например, разрешите POST-запросы от и . Если параметр не определен, реферер должен соответствовать заголовку HTTP . CSRF_COOKIE_DOMAIN = ‘.exemple.com’ www.exemple.com api.exemple.com Host Расширение принятых рефереров за пределы текущего хоста или домена cookie можно выполнить с помощью этой настройки CSRF_TRUSTED_ORIGINS .
Это гарантирует, что для возврата данных с запросом POST можно использовать только формы, исходящие из доверенных доменов.
Запросы GET намеренно игнорируются (как и другие запросы, определенные как «безопасные» RFC 7231 # раздел-4.2.1 ). Эти запросы никогда не должны иметь потенциально опасных побочных эффектов, и в этом случае CSRF-атака с запросом GET должна быть безвредной. RFC 7231 # section-4.2.1 определяет методы POST, PUT и DELETE как «небезопасные», и все другие методы также считаются небезопасными для максимальной защиты.
Защита CRSF не может защитить от атак «злоумышленник посередине», поэтому HTTPS следует использовать со строгой безопасностью транспорта HTTP (HSTS) . Также предполагается, что заголовок HOST был проверен и что на сайте нет уязвимостей межсайтового скриптинга (поскольку этот тип уязвимости уже позволяет злоумышленнику делать то, что делает уязвимость CSRF, и больше).
Удаление заголовка Referer
Кеширование ¶
Если тег шаблона 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): .
Если вы используете представления на основе классов, вы можете обратиться к разделу «Украшение представлений на основе классов» .
Тесты ¶
Обычно CsrfViewMiddleware затрудняет тестирование функций просмотра, потому что токен CSRF должен отправляться с каждым запросом POST. Таким образом, HTTP-клиент Django, используемый для тестирования, был изменен для автоматической пометки запросов и, таким образом, информирования промежуточного программного обеспечения и декоратора, csrf_protect чтобы они не отклоняли эти запросы. Во всем остальном (например, отправка файлов cookie и т. Д.) Поведение во время тестирования такое же.
Если по какой-то причине вы хотите, чтобы HTTP-клиент, используемый для тестирования, выполнял проверки CSRF, вы можете создать экземпляр тестового клиента, который применяет проверки CSRF:
>>> from django.test import Client >>> csrf_client = Client(enforce_csrf_checks=True)
Ограничения ¶
Поддомены сайта могут размещать файлы cookie на клиенте для всего домена. Установив файл cookie и используя соответствующий токен, поддомены смогут обойти защиту CSRF. Единственный способ избежать этого — убедиться, что поддомены контролируются доверенными пользователями (или, по крайней мере, не могут устанавливать файлы cookie). Обратите внимание, что даже без CSRF существуют другие уязвимости, такие как фиксация сеанса, из-за которых выдача субдоменов ненадежным третьим сторонам является плохой идеей; эти уязвимости не могут быть легко устранены с помощью текущих браузеров.
Особые случаи ¶
Некоторые представления могут иметь необычные требования, которые подразумевают, что они не соответствуют нормальной модели, рассматриваемой здесь. В таких ситуациях может быть полезен ряд утилит. Сценарии, которые могут потребоваться, описаны в следующем разделе.
Утилиты ¶
Приведенные ниже примеры относятся к представлениям на основе функций. Если вы используете представления на основе классов, вы можете обратиться к разделу «Украшение представлений на основе классов» .
Этот декоратор отмечает представление как освобожденное от защиты, обеспечиваемой промежуточным программным обеспечением. Пример:
from django.http import HttpResponse from django.views.decorators.csrf import csrf_exempt @csrf_exempt def my_view(request): return HttpResponse('Hello world')
requires_csrf_token ( просмотр ) ¶
Обычно тег шаблона 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 ( просмотр ) ¶
Этот декоратор заставляет представление отправлять файл cookie CSRF.
Сценарии ¶
Для некоторых представлений необходимо отключить защиту CSRF ¶
Большинство представлений требуют защиты CSRF, но некоторые нет.
Обходной путь: вместо отключения промежуточного программного обеспечения и применения csrf_protect ко всем представлениям, которые в нем нуждаются, включите промежуточное программное обеспечение и используйте его csrf_exempt() .
CsrfViewMiddleware.process_view не используется ¶
Бывают случаи, когда он CsrfViewMiddleware.process_view не будет выполнен до вашего просмотра — например, обработчики ошибок 404 и 500 — но вам все равно нужен токен CSRF в форме.
Незащищенное представление требует токена CSRF ¶
Некоторые представления могут не быть защищены, возможно, исключены csrf_exempt , но все же должны включать токен CSRF.
Решение: используйте с csrf_exempt() последующим requires_csrf_token() (т.е. requires_csrf_token должен быть самым внутренним декоратором).
Вид нуждается в защите для определенного пути ¶
Вид нуждается в защите CSRF только при соблюдении определенного количества условий и не должен защищаться в остальное время.
Обходной путь : используйте csrf_exempt() для всей функции просмотра и, в csrf_protect() частности, для пути, который необходимо защитить. Пример:
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()
Страница использует AJAX без HTML-формы ¶
Страница выполняет запрос POST через AJAX, и на этой странице нет HTML-формы с тегом, csrf_token который мог бы вызвать отправку файла cookie CSRF.
Решение: используйте ensure_csrf_cookie() в представлении, которое отправляет страницу.
Встроенные и многоразовые приложения ¶
Поскольку разработчик может отключить промежуточное ПО CsrfViewMiddleware , все затронутые представления в приложениях Contrib Django используют декоратор, 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
Часто задаваемые вопросы ¶
Является ли отправка пары произвольных токенов CSRF (данные cookie и POST) уязвимостью? ¶
Нет, сознательно нет. Без атаки «человек посередине» у злоумышленника нет возможности отправить файл cookie с токеном CSRF в браузер своей жертвы; Успешная атака должна иметь возможность получить cookie из браузера жертвы через XSS или другие подобные средства, и в этом случае злоумышленнику обычно не нужно атаковать через CSRF.
Некоторые инструменты аудита безопасности сообщают об этом как о проблеме, но, как упоминалось выше, злоумышленник не может украсть файл cookie CSRF из браузера пользователя. Возможность «украсть» или изменить собственный токен с помощью Firebug, инструментов разработчика Chrome и т. Д. не означает, что это уязвимость.
Проблематично ли, что защита Django CSRF по умолчанию не привязана к сеансу? ¶
Нет, сознательно нет. Отсутствие привязки защиты CSRF к сеансу позволяет использовать защиту на таких сайтах, как pastebin, которые разрешают отправку данных анонимным пользователям, у которых нет сеанса.
Если вы хотите сохранить токен CSRF в сеансе пользователя, установите параметр CSRF_USE_SESSIONS .
Почему после входа в систему пользователь может получить ошибку проверки CSRF? ¶
По соображениям безопасности токены CSRF меняются при каждом подключении пользователя. На любой странице, содержащей форму, созданную до входа в систему, будет старый недопустимый токен CSRF, и ее необходимо будет перезагрузить. Это может произойти, если пользователь нажмет кнопку «Назад» после входа в систему или войдет в другую вкладку браузера.