Rest django framework отключить csrf
Обновлено: 28.06.2024
Я ищу простой способ отключить всю проверку CSRF , чтобы проверить мой API в Postman.
До сих пор я безуспешно пытался добавить @decorator csrf_exempt . Я также попытался создать файл disable.py внутри приложения, но тоже не сработал.
Кроме того, я хочу деактивировать все запросы, так что каким-то образом не нужно добавлять декоратор везде. Этот проект, который я только что получил, уже находится в производстве, но я хочу начать писать тесты сначала в Postman, а затем в TestCases.
Все мои взгляды используют " api_generics.CRUDGeneric",
объявление этого класса является:
спасибо это совет
1 ответ
У меня есть следующее мнение: @api_view(POST?) @csrf_exempt def user_login(request): это соответствует django rest framework. Как я могу сделать это представление csrf освобожденным? Я пытаюсь сделать API звонков через iphone.
@62009030 вы должны быть в состоянии сделать то, о чем упоминал @smarber.. Это тоже может сработать.. Это пройденный путь для добавления csrf_exempt
Это может быть обходной путь для вашей проблемы..
Похожие вопросы:
Без Django Rest Framework, которые я использовал для создания формы / POST запросы вроде так: <form method=post action=/register/> . </form> но я.
Я знаю, что есть ответы относительно Django Rest Framework, но я не мог найти решение своей проблемы. У меня есть приложение, которое имеет аутентификацию и некоторые функциональные возможности. Я.
У меня есть одностраничное приложение angularjs, использующее аутентификацию JWT. Поскольку JWTs отправляются с каждым отдельным запросом, кажется излишним использовать токены CSRF в моих формах.
Я пытаюсь использовать Vue.js, чтобы сделать некоторые методы POST для моего REST Api, которые я создал с помощью Django Rest Framework. Проблема в том, что я получаю ошибку CSRF Failed: CSRF token.
У меня есть следующее мнение: @api_view(POST?) @csrf_exempt def user_login(request): это соответствует django rest framework. Как я могу сделать это представление csrf освобожденным? Я пытаюсь.
Я использую django rest framework для выполнения API вызовов через IOS и получаю следующую ошибку CSRF Failed: CSRF cookie not set. Вот мой код django API: class LoginView(APIView): List all.
Я использую Django + Django REST Framework + Django OAuth инструментарий. Я понимаю, что AJAX вызовов из веб-сеанса требуют защиты CSRF, но, насколько я понимаю, мобильные приложения этого не.
Я разработал простой веб-сервис, но не смог использовать post с Django Rest Framework, так как он жалуется на CSRF: detail: CSRF Failed: CSRF cookie not set. Удаление декоратора api_view.
Я не могу понять, можно ли создать django api без django rest framework, потому что у меня возникли проблемы с токеном csrf при получении моих данных POST. Можно ли отключить это, потому что я не.
Я знаю, что есть ответы относительно Django Rest Framework, но я не мог найти решение своей проблемы.
у меня есть приложение, которое имеет аутентификацию и некоторые функции. Я добавил к нему новое приложение, которое использует Django Rest Framework. Я хочу использовать библиотеку только в этом приложении. Также я хочу сделать запрос POST, и я всегда получаю этот ответ:
у меня есть следующий код:
Я хочу добавить API без влияет на текущее приложение. Итак, мои вопросы: как я могу отключить CSRF только для этого приложения ?
почему эта ошибка происходит?
это происходит из-за значения по умолчанию SessionAuthentication схема, используемая DRF. ДРФ это SessionAuthentication использует структуру сеанса Django для аутентификации, которая требует проверки CSRF.
когда вы не определите ни authentication_classes в вашем представлении/наборе представлений DRF использует эти классы аутентификации по умолчанию.
С ФПИ должен поддерживать оба сеанса и вне сеанса проверки подлинности на основе той же представления, он обеспечивает проверку CSRF только для аутентифицированных пользователей. Это означает, что только аутентифицированные запросы требуют токенов CSRF и анонимные запросы могут быть отправлены без токенов CSRF.
что делать тогда?
теперь, чтобы отключить проверку csrf, вы можете создать пользовательский класс аутентификации CsrfExemptSessionAuthentication который простирается от значения по умолчанию SessionAuthentication класса. В этом классе аутентификации мы переопределим enforce_csrf() проверьте, что происходило внутри фактического SessionAuthentication .
на ваш взгляд, тогда вы можете определить authentication_classes будет:
это должно обрабатывать ошибку csrf.
In views.py, используйте фигурные скобки CsrfExemptMixin и authentication_classes:
Если вы не хотите использовать аутентификацию на основе сеанса, вы можете удалить Session Authentication из REST_AUTHENTICATION_CLASSES, и это автоматически удалит все проблемы на основе csrf. Но в этом случае Browseable apis может не работать.
кроме того, эта ошибка не должна возникать даже при аутентификации сеанса. Вы должны использовать пользовательскую аутентификацию, такую как TokenAuthentication для ваших API, и обязательно отправьте Accept:application/json и Content-Type:application/json (при условии, что вы используете json) в ваших запросах вместе с маркер аутентификации.
для всех, кто не нашел полезного ответа. Да DRF автоматически удаляет защиту CSRF, если вы не используете SessionAuthentication класс аутентификации, например, многие разработчики используют только JWT:
но проблема CSRF not set может произойти по какой-то другой причине, для примера вы неправильно добавили путь к вам:
Если вы управляете своими маршрутами в urls.py, вы можете обернуть нужные маршруты с помощью csrf_exempt (), чтобы исключить их из промежуточного программного обеспечения проверки CSRF.
альтернативно, как декоратор Некоторые могут найти использование декоратора @csrf_exempt более подходящим для их нужд
должен получить работу!
Я поражен той же проблемой. Я последовал за этим ссылка и это сработало. Решение заключается в создании промежуточного слоя
добавить disable.py файл в одном из ваших приложений (в моем случае это "myapp")
и добавьте middileware в MIDDLEWARE_CLASSES
если вы используете эксклюзивную виртуальную среду для своего приложения, вы можете использовать следующий подход без эффективных других приложений.
то, что вы наблюдали, происходит потому что rest_framework/authentication.py этот код authenticate метод SessionAuthentication класс:
вы можете изменить Request класс для свойства с именем csrf_exempt и инициализировать его внутри вашего соответствующего класса представления в True если вы не хотите проверки CSRF. Для пример:
далее модифицировать приведенный выше код следующим образом:
мое решение показано удар. Просто укрась мой класс.
между изменениями DNS это также может быть фактором. Ожидание полного сброса DNS решит эту проблему, если она работала до проблем/изменений DNS.
Промежуточное ПО CSRF и теги шаблонов упрощают защиту от атак с подделкой межсайтовых запросов . Этот тип атаки происходит, когда вредоносный веб-сайт содержит ссылку, кнопку формы или фрагмент кода JavaScript, который предназначен для выполнения действия на вашем веб-сайте с использованием учетных данных авторизованного пользователя, который посещает вредоносный сайт в своем браузере. Также рассматривается родственный тип атаки: «CSRF login», когда атакующий сайт обманывает браузер пользователя, подключаясь к сайту с чужими учетными данными.
Как пользоваться ¶
Чтобы воспользоваться преимуществами защиты CSRF в представлениях, сделайте следующее:
По умолчанию промежуточное ПО CSRF включено в настройках MIDDLEWARE . Если вы переопределите этот параметр, помните, что это 'django.middleware.csrf.CsrfViewMiddleware' должно происходить до того, как промежуточное ПО, которое полагается на CSRF-атаки, уже было отражено.
Если вы отключите его, что не рекомендуется, вы можете использовать его csrf_protect() в некоторых представлениях, которые хотите защитить (см. Ниже).
В любом шаблоне, который использует форму POST, используйте тег шаблона csrf_token внутри тега HTML, <form> если форма ссылается на внутренний URL-адрес, например:
С другой стороны, этого не следует делать для форм POST, нацеленных на внешние URL-адреса, поскольку это приведет к раскрытию токена CSRF и, таким образом, приведет к уязвимости.
В соответствующих функциях просмотра проверьте, что RequestContext используется для создания ответа, чтобы он работал правильно. Если вы используете функцию , общие представления или дополнительные приложения, не нужно беспокоиться, потому что все эти представления используют . render() RequestContext
Рекомендуемым источником для токена является файл cookie csrftoken , который будет присутствовать, если у вас включена защита CSRF для вашего представления, как показано выше.
Файл cookie CSRF имеет имя csrftoken по умолчанию, но вы можете изменить это имя в настройках CSRF_COOKIE_NAME .
Получить токен можно так:
Приведенный выше код можно упростить, заменив библиотеку Cookie JavaScript getCookie :
Маркер CSRF также присутствует в DOM, но только если он явно включен с помощью тега csrf_token в шаблоне. Файл cookie будет содержать стандартный токен; он CsrfViewMiddleware предпочтет cookie токену DOM. В любом случае вы гарантированно получите cookie, если токен присутствует в DOM, поэтому лучше использовать cookie!
Если представление не использует шаблон, содержащий тег csrf_token , Django может не установить файл cookie CSRF. Такая ситуация часто возникает в случаях, когда формы динамически добавляются на страницу. Чтобы решить эту проблему, Django предоставляет вид декоратора , который заставляет использовать куки: ensure_csrf_cookie() .
Установка токена для запроса AJAX ¶
Наконец, вам нужно установить заголовок для вашего запроса AJAX. Используя API fetch () :
Использование CSRF в шаблонах Jinja2 ¶
Jinja2 Механизм шаблонов Django добавляет контекст всех шаблонов, что эквивалентно языку шаблонов Django. Например : >
Метод декоратора ¶
Вместо того, чтобы добавлять CsrfViewMiddleware в качестве общей защиты, вы можете использовать декоратор csrf_protect , который предлагает точно такую же функциональность, для конкретных представлений, которые нуждаются в защите. Этот декоратор следует использовать как в представлениях, которые включают в себя токен CSRF, так и в представлениях, которые принимают данные формы POST. (Часто это одна и та же функция просмотра, но не всегда).
Не рекомендуется прибегать к использованию одного декоратора , потому что, если вы забудете его использовать, у вас будет дыра в безопасности. Стратегия «пояс и подтяжки» с использованием того и другого хороша и приведет лишь к минимальной перегрузке.
Декоратор, обеспечивающий защиту представления, подобную промежуточному программному обеспечению CsrfViewMiddleware .
Если вы используете представления на основе классов, вы можете обратиться к разделу «Украшение представлений на основе классов» .
Отклоненные запросы ¶
По умолчанию пользователю возвращается ответ «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() поэтому значение поля формы изменяется в каждом таком ответе.
Это действие выполняется тегом шаблона.
При проверке значения поля csrfmiddlewaretoken только секретное значение, а не полный токен, сравнивается с секретным значением содержимого cookie. Это позволяет использовать постоянно меняющиеся токены. Хотя каждый запрос может использовать свой токен, секретное значение остается общим для всех.
Эта проверка выполняется промежуточным программным обеспечением CsrfViewMiddleware .
Расширение принятых рефереров за пределы текущего хоста или домена cookie можно выполнить с помощью этой настройки CSRF_TRUSTED_ORIGINS .
Это гарантирует, что для возврата данных с запросом POST можно использовать только формы, исходящие из доверенных доменов.
Удаление заголовка Referer
Чтобы избежать раскрытия URL-адреса реферера сторонним сайтам, может быть желательно отключить реферер в тегах <a> вашего сайта. Например, можно использовать тег или включить заголовок . Из-за строгого контроля реферера в защите CSRF для запросов HTTPS эти методы приводят к сбоям CSRF для «небезопасных» запросов методов. Лучше использовать альтернативы, такие как ссылки на сторонние сайты. <meta name="referrer" content="no-referrer"> Referrer-Policy: no-referrer <a rel="noreferrer" . >"
Кеширование ¶
Если тег шаблона csrf_token используется шаблоном (или функция get_token вызывается другим способом), промежуточное ПО CsrfViewMiddleware добавляет в ответ файл cookie и заголовок . Это означает, что промежуточное ПО будет хорошо работать с промежуточным ПО кеширования, если оно используется в соответствии с инструкциями ( должно быть помещено в настройки перед любым другим промежуточным ПО). Vary: Cookie UpdateCacheMiddleware
Однако, если вы используете декораторы кеша для отдельных представлений, промежуточное ПО CSRF еще не сможет установить заголовок Vary или файл cookie CSRF, и ответ будет кэшироваться без них. Другой. В этом случае в представлениях, которые требуют вставки токена CSRF, вы должны django.views.decorators.csrf.csrf_protect() сначала использовать декоратор функции :
Если вы используете представления на основе классов, вы можете обратиться к разделу «Украшение представлений на основе классов» .
Тесты ¶
Ограничения ¶
Поддомены сайта могут размещать файлы cookie на клиенте для всего домена. Установив файл cookie и используя соответствующий токен, поддомены смогут обойти защиту CSRF. Единственный способ избежать этого - убедиться, что поддомены контролируются доверенными пользователями (или, по крайней мере, не могут устанавливать файлы cookie). Обратите внимание, что даже без CSRF существуют другие уязвимости, такие как фиксация сеанса, из-за которых выдача субдоменов ненадежным третьим сторонам является плохой идеей; эти уязвимости не могут быть легко устранены с помощью текущих браузеров.
Особые случаи ¶
Некоторые представления могут иметь необычные требования, которые подразумевают, что они не соответствуют нормальной модели, рассматриваемой здесь. В таких ситуациях может быть полезен ряд утилит. Сценарии, которые могут потребоваться, описаны в следующем разделе.
Утилиты ¶
Приведенные ниже примеры относятся к представлениям на основе функций. Если вы используете представления на основе классов, вы можете обратиться к разделу «Украшение представлений на основе классов» .
Этот декоратор отмечает представление как освобожденное от защиты, обеспечиваемой промежуточным программным обеспечением. Пример:
Обычно тег шаблона csrf_token не работает, если не CsrfViewMiddleware.process_view использовался аналогичный аналог csrf_protect . Декоратор представления requires_csrf_token можно использовать, чтобы убедиться, что тег шаблона работает. Этот декоратор работает аналогично csrf_protect , но никогда не отклоняет входящий запрос.
Этот декоратор заставляет представление отправлять файл 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() частности, для пути, который необходимо защитить. Пример:
Решение: используйте ensure_csrf_cookie() в представлении, которое отправляет страницу.
Встроенные и многоразовые приложения ¶
Поскольку разработчик может отключить промежуточное ПО CsrfViewMiddleware , все затронутые представления в приложениях Contrib Django используют декоратор, csrf_protect чтобы гарантировать, что эти приложения защищены от атак CSRF. Рекомендуется, чтобы разработчики других многоразовых приложений, которые хотят предложить те же гарантии, также использовали декоратор csrf_protect для своих представлений.
Настройки ¶
Для управления поведением Django против CSRF можно использовать ряд настроек:
Часто задаваемые вопросы ¶
Является ли отправка пары произвольных токенов CSRF (данные cookie и POST) уязвимостью? ¶
Некоторые инструменты аудита безопасности сообщают об этом как о проблеме, но, как упоминалось выше, злоумышленник не может украсть файл cookie CSRF из браузера пользователя. Возможность «украсть» или изменить собственный токен с помощью Firebug, инструментов разработчика Chrome и т. Д. не означает, что это уязвимость.
Проблематично ли, что защита Django CSRF по умолчанию не привязана к сеансу? ¶
Нет, сознательно нет. Отсутствие привязки защиты CSRF к сеансу позволяет использовать защиту на таких сайтах, как pastebin, которые разрешают отправку данных анонимным пользователям, у которых нет сеанса.
Если вы хотите сохранить токен CSRF в сеансе пользователя, установите параметр CSRF_USE_SESSIONS .
Почему после входа в систему пользователь может получить ошибку проверки CSRF? ¶
Промежуточное ПО CSRF и тег шаблона обеспечивают простую в использовании защиту от Cross Site Request Forgeries. Этот тип атаки возникает, когда вредоносный сайт содержит ссылку, кнопку формы или какой-либо JavaScript, предназначенный для выполнения некоторого действия на вашем сайте, используя учетные данные вошедшего в систему пользователя, который посещает вредоносный сайт в своем браузере. Также рассматривается смежный тип атаки, „login CSRF“, когда атакующий сайт обманом заставляет браузер пользователя войти на сайт с чужими учетными данными.
Как его использовать¶
Чтобы воспользоваться преимуществами защиты от CSRF в ваших представлениях, выполните следующие шаги:
По умолчанию промежуточное ПО CSRF активировано в настройках MIDDLEWARE . Если вы переопределите эту настройку, помните, что 'django.middleware.csrf.CsrfViewMiddleware' должно стоять перед любым промежуточным ПО представления, которое предполагает, что CSRF-атаки были обработаны.
Если вы отключили его, что не рекомендуется, вы можете использовать csrf_protect() на определенных представлениях, которые вы хотите защитить (см. ниже).
В любом шаблоне, использующем форму POST, используйте тег csrf_token внутри элемента <form> , если форма предназначена для внутреннего URL, например:
Этого не следует делать для POST-форм, нацеленных на внешние URL, поскольку в этом случае произойдет утечка CSRF-токена, что приведет к уязвимости.
В соответствующих функциях представления убедитесь, что RequestContext используется для рендеринга ответа, чтобы работал правильно. Если вы используете функцию render() , общие представления или приложения contrib, вы уже защищены, поскольку все они используют RequestContext .
Рекомендуемым источником маркера является cookie csrftoken , который будет установлен, если вы включили защиту CSRF для ваших представлений, как описано выше.
По умолчанию маркер CSRF имеет имя csrftoken , но вы можете управлять именем cookie с помощью параметра CSRF_COOKIE_NAME .
Приобрести токен очень просто:
Приведенный выше код можно упростить, используя JavaScript Cookie library для замены getCookie :
CSRF-токен также присутствует в DOM, но только если он явно включен в шаблон с помощью csrf_token . Cookie содержит канонический токен; CsrfViewMiddleware предпочтет cookie токену в DOM. Независимо от этого, вы гарантированно получите cookie, если маркер присутствует в DOM, поэтому вы должны использовать cookie!
Если ваше представление не выводит шаблон, содержащий тег шаблона csrf_token , Django может не установить куки CSRF-токена. Это часто встречается в случаях, когда формы динамически добавляются на страницу. Для решения этой проблемы Django предоставляет декоратор представления, который принудительно устанавливает cookie: ensure_csrf_cookie() .
Установка маркера в запросе AJAX¶
Наконец, вам придется фактически установить заголовок в запросе AJAX, при этом защитив токен CSRF от отправки на другие домены с помощью settings.crossDomain в jQuery 1.5.1 и новее:
Использование CSRF в шаблонах Jinja2¶
Бэкенд шаблонов Django Jinja2 добавляет > в контекст всех шаблонов, что эквивалентно в языке шаблонов Django. Например:
Метод декоратора¶
Вместо того чтобы добавлять CsrfViewMiddleware в качестве абсолютной защиты, вы можете использовать декоратор csrf_protect , который имеет точно такую же функциональность, в определенных представлениях, которые нуждаются в защите. Он должен использоваться ** как** для представлений, которые вставляют CSRF-токен в вывод, так и для тех, которые принимают данные POST-формы. (Часто это одна и та же функция представления, но не всегда).
Использование декоратора само по себе не рекомендуется, поскольку если вы забудете его использовать, у вас будет дыра в безопасности. Стратегия «пояса и скобок», при которой используются оба декоратора, вполне подходит, и накладные расходы будут минимальными.
Декоратор, обеспечивающий защиту CsrfViewMiddleware для представления.
Если вы используете представления на основе классов, вы можете обратиться к Decorating class-based views .
Отклоненные запросы¶
По умолчанию пользователю отправляется ответ „403 Forbidden“, если входящий запрос не проходит проверку, выполняемую CsrfViewMiddleware . Обычно это происходит только в случае настоящей подделки межсайтового запроса, или когда из-за ошибки программирования CSRF-токен не был включен в POST-форму.
Однако страница ошибки не очень дружелюбна, поэтому вы можете захотеть создать собственное представление для обработки этого условия. Для этого просто установите параметр CSRF_FAILURE_VIEW .
Сбои CSRF регистрируются как предупреждения в журнале django.security.csrf .
Как это работает¶
Защита от CSRF основана на следующих моментах:
CSRF-куки, основанные на случайном секретном значении, к которому другие сайты не будут иметь доступа.
Этот файл cookie устанавливается функцией CsrfViewMiddleware . Он отправляется с каждым ответом, в котором был вызван django.middleware.csrf.get_token() (функция, используемая для получения маркера CSRF), если он еще не был установлен в запросе.
Для защиты от атак BREACH токен - это не просто секрет; к секрету добавляется случайная соль, которая используется для скремблирования.
В целях безопасности значение секрета изменяется каждый раз, когда пользователь входит в систему.
Скрытое поле формы с именем „csrfmiddlewaretoken“, присутствующее во всех исходящих POST-формах. Значение этого поля - это, опять же, значение секрета с солью, которая добавляется к нему и используется для скремблирования. Соль обновляется при каждом вызове get_token() , так что значение поля формы изменяется в каждом таком ответе.
Эту часть выполняет тег шаблона.
При проверке значения поля „csrfmiddlewaretoken“ только секрет, а не полный токен, сравнивается с секретом в значении cookie. Это позволяет использовать постоянно меняющиеся маркеры. Хотя каждый запрос может использовать свой собственный токен, секрет остается общим для всех.
Эта проверка выполняется с помощью CsrfViewMiddleware .
Расширить список принимаемых ссылок за пределы текущего хоста или домена cookie можно с помощью параметра CSRF_TRUSTED_ORIGINS .
Это гарантирует, что только формы, полученные из доверенных доменов, могут быть использованы для POST данных.
Удаление заголовка Referer
Кэширование¶
Если тег шаблона csrf_token используется шаблоном (или функция get_token вызывается каким-либо другим способом), CsrfViewMiddleware добавит cookie и заголовок Vary: Cookie в ответ. Это означает, что промежуточное ПО будет хорошо взаимодействовать с промежуточным ПО кэша, если оно используется в соответствии с инструкциями ( UpdateCacheMiddleware идет перед всеми другими промежуточными ПО).
Однако, если вы используете декораторы кэша на отдельных представлениях, промежуточное ПО CSRF еще не сможет установить заголовок Vary или куки CSRF, и ответ будет кэширован без них. В этом случае для всех представлений, которые потребуют вставки маркера CSRF, следует сначала использовать декоратор django.views.decorators.csrf.csrf_protect() :
Если вы используете представления на основе классов, вы можете обратиться к Decorating class-based views .
Тестирование¶
Если по какой-то причине вы хотите, чтобы тестовый клиент выполнял проверку CSRF, вы можете создать экземпляр тестового клиента, который будет выполнять проверку CSRF:
Ограничения¶
Краевые случаи¶
Определенные представления могут иметь необычные требования, которые означают, что они не вписываются в обычную схему, предусмотренную здесь. В таких ситуациях может быть полезен ряд утилит. Сценарии, в которых они могут понадобиться, описаны в следующем разделе.
Утилиты¶
Приведенные ниже примеры предполагают, что вы используете представления на основе функций. Если вы работаете с представлениями на основе классов, вы можете обратиться к Decorating class-based views .
Этот декоратор помечает представление как освобожденное от защиты, обеспечиваемой промежуточным ПО. Пример:
Обычно тег шаблона csrf_token не работает, если не запущен тег CsrfViewMiddleware.process_view или эквивалентный ему csrf_protect . Декоратор представления requires_csrf_token может быть использован для обеспечения работы тега шаблона. Этот декоратор работает аналогично csrf_protect , но никогда не отклоняет входящий запрос.
Этот декоратор заставляет представление отправлять CSRF cookie.
Сценарии¶
Защита 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() для пути внутри нее, который нуждается в защите. Пример:
Решение: используйте ensure_csrf_cookie() в представлении, которое отправляет страницу.
Contrib и многократно используемые приложения¶
Поскольку разработчик может отключить CsrfViewMiddleware , все соответствующие представления в приложениях contrib используют декоратор csrf_protect для обеспечения безопасности этих приложений от CSRF. Рекомендуется, чтобы разработчики других многократно используемых приложений, которые хотят получить такие же гарантии, также использовали декоратор csrf_protect в своих представлениях.
Настройки¶
Для управления поведением Django в отношении CSRF можно использовать ряд настроек:
Часто задаваемые вопросы¶
Является ли размещение произвольной пары CSRF-токенов (cookie и POST-данные) уязвимостью?¶
Некоторые инструменты аудита безопасности отмечают это как проблему, но, как уже говорилось, злоумышленник не может украсть CSRF-куки браузера пользователя. «Кража» или изменение собственного маркера с помощью Firebug, инструментов разработчика Chrome и т.д. не является уязвимостью.
Является ли проблемой то, что защита CSRF в Django по умолчанию не связана с сессией?¶
Если вы хотите хранить CSRF-токен в сессии пользователя, используйте параметр CSRF_USE_SESSIONS .
Почему пользователь может столкнуться с ошибкой проверки CSRF после входа в систему?¶
В целях безопасности маркеры CSRF меняются каждый раз, когда пользователь входит в систему. Любая страница с формой, созданной до входа в систему, будет иметь старый, недействительный CSRF-токен, и ее необходимо будет перезагрузить. Это может произойти, если пользователь использует кнопку «назад» после входа в систему или если он входит в другую вкладку браузера.
Читайте также: