Промежуточное ПО

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

Доступное промежуточное ПО

ПО промежуточного слоя кеширования

класс UpdateCacheMiddleware
класс FetchFromCacheMiddleware

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

Обычное промежуточное ПО

класс CommonMiddleware

Добавляет несколько удобств для перфекционистов:

  • Запрещает доступ к пользовательским агентам (браузерам), упомянутым в настройке DISALLOWED_USER_AGENTS , которые должны содержать список скомпилированных объектов регулярных выражений.

  • Выполняет перезапись URL на основе настроек APPEND_SLASH и PREPEND_WWW .

    Если APPEND_SLASH равно, True и исходный URL-адрес не заканчивается косой чертой и URL-адрес не найден в конфигурации URL-адреса, новый URL-адрес формируется путем добавления косой черты в конце. Если новый URL-адрес находится в конфигурации URL-адреса, Django перенаправляет запрос на этот URL-адрес. В противном случае начальный URL обрабатывается как обычно.

    Например, foo.com/bar будет перенаправлен , foo.com/bar/ если не правильный образец URL для foo.com/bar но это правильный образец для foo.com/bar/ .

    Если это PREPEND_WWW правда True , URL-адреса не начинаются с www. «Будет перенаправлен на тот же URL, начинающийся с« www. ».

    Эти два варианта направлены на нормализацию URL-адресов. Идея состоит в том, что каждый URL-адрес должен существовать в одной и только одной форме. Технически URL-адрес foo.com/bar отличается от foo.com/bar/ - индекс поисковой системы рассматривал бы их как отдельные URL-адреса - что оправдывает хорошую практику нормализации URL-адресов.

  • Устанавливает заголовок Content-Length для ответов, которые не относятся к типу stream.

CommonMiddleware.response_redirect_class

По умолчанию это HttpResponsePermanentRedirect . Создайте подкласс CommonMiddleware и переопределите этот атрибут, чтобы настроить перенаправления, создаваемые промежуточным программным обеспечением.

класс BrokenLinkEmailsMiddleware

Промежуточное ПО GZip

класс GZipMiddleware

Предупреждение

Исследователи безопасности недавно обнаружили, что когда GZipMiddleware на веб-сайте используются методы сжатия (в том числе методы сжатия ), этот сайт может подвергнуться ряду потенциальных атак. Перед использованием GZipMiddleware на своем сайте вы должны тщательно оценить, являетесь ли вы возможной целью этих атак. Если у вас есть какие-либо сомнения по этому поводу, вам следует избегать использования этого промежуточного программного обеспечения. Дополнительные сведения см. В документе об уязвимости (PDF) и на сайте breachattack.com .

По промежуточного слоя django.middleware.gzip.GZipMiddleware сжимает контент для браузеров, поддерживающих сжатие GZip (все современные браузеры).

Это промежуточное ПО должно быть размещено перед любым другим промежуточным ПО, которое должно читать или записывать тело ответа, чтобы сжатие могло произойти после.

Он НЕ сжимает контент, если выполняется одно из следующих условий:

  • Размер тела содержимого меньше 200 байт.
  • В ответе уже установлен заголовок Content-Encoding .
  • Запрос (браузер) не послать заголовок в Accept-Encoding том числе gzip .

Если ответ имеет заголовок ETag , ETag становится слабым, чтобы соответствоватьRFC 7232 # section-2.1 .

Вы можете применить сжатие GZip для отдельных представлений с помощью декоратора gzip_page() .

Условное ПО промежуточного слоя GET

класс ConditionalGetMiddleware

Обрабатывает условные операции GET. Если ответ не имеет заголовка ETag , промежуточное ПО создает его при необходимости. Если ответ имеет заголовок ETag или, Last-Modified а запрос имеет заголовок If-None-Match или If-Modified-Since , ответ заменяется на HttpResponseNotModified .

Промежуточное ПО для локали ¶

класс LocaleMiddleware

Активирует выбор языка по данным запроса. Затем контент персонализируется пользователем. См. Документацию по интернационализации .

LocaleMiddleware.response_redirect_class

По умолчанию это HttpResponseRedirect . Создайте подкласс LocaleMiddleware и переопределите этот атрибут, чтобы настроить перенаправления, создаваемые промежуточным программным обеспечением.

ПО промежуточного слоя для сообщений

класс MessageMiddleware

Включает поддержку сообщений для каждого сеанса или для каждого файла cookie. См. Документацию по сообщениям .

Промежуточное ПО безопасности

Предупреждение

Если ваша ситуация развертывания позволяет, обычно лучше делегировать функции, предоставляемые промежуточным программным обеспечением, интерфейсному веб-серверу SecurityMiddleware . Таким образом, если некоторые запросы не предоставляются Django (например, статические файлы или файлы, отправленные пользователями), они будут иметь такую ​​же защиту, как запросы, обслуживаемые приложением Django.

класс SecurityMiddleware

Промежуточное ПО django.middleware.security.SecurityMiddleware обеспечивает несколько улучшений безопасности для цикла запроса / ответа. Каждое улучшение можно включить или выключить независимо от настройки.

Строгая безопасность транспорта HTTP (HSTS)

Для сайтов, доступ к которым должен быть возможен только через HTTPS, вы можете указать современным браузерам запрещать подключения к вашему доменному имени, если подключение небезопасно (в течение определенного периода времени), установив вход Заведующий "Строго-Транспорт-Безопасность" . Это снижает подверженность определенным атакам типа "злоумышленник посередине" (MITM) путем перехвата SSL.

SecurityMiddleware устанавливает этот заголовок для всех ответов HTTPS, если вы установите SECURE_HSTS_SECONDS ненулевое целочисленное значение.

При включении HSTS рекомендуется сначала использовать низкое значение для тестирования, например, в течение одного часа. Каждый раз, когда веб-браузер читает заголовок HSTS для вашего сайта, он отказывается небезопасно связываться (через HTTP) с вашим доменом в течение указанного периода времени. После того, как вы получите подтверждение, что все ресурсы вашего сайта обслуживаются безопасным способом (т.е. HSTS вообще ничего не ломает), можно и желательно увеличить это значение, чтобы случайные посетители защищенный (обычно 31 536 000 секунд, то есть 1 год).SECURE_HSTS_SECONDS = 3600

Кроме того , если вы установите параметр SECURE_HSTS_INCLUDE_SUBDOMAINS в True , SecurityMiddleware добавляет директиву includeSubDomains к заголовку Strict-Transport-Security . Это рекомендуется (если все поддомены обслуживаются исключительно по HTTPS), в противном случае ваш сайт может оставаться уязвимым из-за небезопасного подключения к поддомену.

Если вы хотите добавить свой сайт в список предварительной загрузки браузера , установите для параметра SECURE_HSTS_PRELOAD значение True . Это добавляет директиву preload в заголовок Strict-Transport-Security .

Предупреждение

Политика HSTS применяется ко всему домену, а не только к URL-адресу ответа, для которого вы установили этот заголовок. Поэтому его следует использовать только в том случае, если весь домен обслуживается исключительно HTTPS.

Браузеры, которые строго придерживаются заголовка HSTS, будут отказывать пользователям в обходе предупреждений и подключении к сайту с просроченным, самоподписанным или недействительным SSL-сертификатом по любой другой причине. Если вы используете HSTS, убедитесь, что у вас есть сертификаты, и оставайтесь такими!

Заметка

Если ваше развертывание находится за балансировщиком нагрузки или обратным прокси-сервером, и заголовок Strict-Transport-Security не добавляется к вашим ответам, Django может не обнаружить, что он работает в защищенном соединении; затем необходимо определить настройку SECURE_PROXY_SSL_HEADER .

Реферальная политика

Новое в Django 3.0.

Браузеры используют заголовок Referer как способ отправки информации о том, откуда пользователи. При нажатии на ссылку браузер отправляет полный URL-адрес страницы, содержащей ссылку, в качестве реферера. Хотя это может быть полезно в некоторых случаях, например, при знании того, кто ссылается на ваш сайт, это действительно создает проблемы конфиденциальности, уведомляя сайт о том, что пользователь только что посетил другой сайт.

Некоторые браузеры имеют возможность принимать подсказки относительно того, следует ли включать HTTP-заголовок, Referer когда кто-то щелкает ссылку; эта подсказка передается через заголовок Referrer-Policy . Этот заголовок может предложить браузерам три различных варианта поведения:

  • Полный URL: отправьте полный URL в заголовке Referer . Например, если кто-то посетит https://example.com/page.html , заголовок Referer будет содержать "https://example.com/page.html" .
  • Только источник: отправьте рефереру только источник. Источник состоит из протокола, хоста и номера порта (необязательно). Например, если кто-то посещает https://example.com/page.html , происхождение будет https://example.com/ .
  • Нет реферера: заголовок Referer не будет отправлен вообще.

Этот заголовок может сигнализировать браузеру о двух типах условий:

  • Одно и то же происхождение против перекрестного происхождения: связь https://example.com/1.html червей https://example.com/2.html имеет одно и то же происхождение. Связь https://example.com/page.html червя https://not.example.com/page.html имеет перекрестное происхождение.
  • Переход на более раннюю версию протокола: переход на более раннюю версию происходит, если страница, содержащая ссылку, обслуживается по HTTPS, а целевая страница не обслуживается по HTTPS.

Предупреждение

Когда ваш сайт обслуживается по HTTPS, защита Django CSRF требует наличия заголовка Referer , поэтому полное отключение заголовка предотвратит защиту CSRF. Чтобы получить максимальную пользу от отключения заголовков Referer при сохранении защиты CSRF, мы рекомендуем вам включать только рефереры одного и того же происхождения.

SecurityMiddleware может установить Referrer-Policy заголовок для вас в зависимости от SECURE_REFERRER_POLICY настройки (обратите внимание на орфографию: браузеры отправляют Referer заголовок, когда пользователь нажимает ссылку, но заголовок, указывающий браузеру, делать ли это, пишется по буквам Referrer-Policy ). Допустимые значения для этого параметра:

no-referrer
Указывает браузеру не отправлять реферер для ссылок, которые нажимаются на этом сайте.
no-referrer-when-downgrade
Указывает браузеру отправить полный URL-адрес в качестве источника перехода, но только если не происходит понижение версии протокола.
origin
Указывает браузеру отправлять в качестве реферера только источник, а не полный URL.
origin-when-cross-origin
Указывает браузеру отправлять полный URL-адрес в качестве реферера для ссылок с одинаковым происхождением, но только источник для ссылок с перекрестным происхождением.
same-origin
Указывает браузеру отправить полный URL-адрес, но только для ссылок одного и того же происхождения. Реферер не отправляется для ссылок из разных источников.
strict-origin
Указывает браузеру отправлять в качестве реферера только источник, а не полный URL, и не отправлять реферер при переходе на более раннюю версию протокола.
strict-origin-when-cross-origin
Указывает браузеру отправить полный URL-адрес, если ссылка имеет то же происхождение и не происходит понижение версии протокола; отправляйте только источник, если ссылка является перекрестным источником, и ничего не отправлять, если происходит понижение версии протокола.
unsafe-url
Указывает браузеру всегда отправлять полный URL-адрес в качестве реферера.

Неизвестные значения политики

Возможно, что некоторые значения политики неизвестны пользовательскому агенту. Таким образом, разрешено указывать несколько значений политики для обеспечения резервного значения. Приоритет отдается последнему понятному значению. Для поддержки этого можно использовать итерируемый объект или строку, разделенную запятыми SECURE_REFERRER_POLICY .

X-Content-Type-Options: nosniff

Некоторые браузеры пытаются угадать типы содержимого ресурсов, которые они вызывают, независимо от заголовка Content-Type . Хотя это может помочь отображать сайты с неправильно настроенными серверами, это также может представлять угрозу безопасности.

Если ваш сайт обслуживает файлы, загруженные пользователями, злоумышленник может загрузить специально написанный файл, который будет интерпретирован браузером как HTML или JavaScript, если вы ожидаете, что его содержимое будет безвредным.

Чтобы браузер не угадывал тип содержимого и заставлял его всегда использовать тип, указанный в заголовке Content-Type , вы можете установить заголовок X-Content-Type-Options: nosniff . SecurityMiddleware делает это для всех ответов, если для параметра SECURE_CONTENT_TYPE_NOSNIFF установлено значение True .

Обратите внимание, что в большинстве ситуаций развертывания, когда Django не участвует в обслуживании файлов, отправленных пользователями, эта настройка не поможет. Например, если содержимое MEDIA_URL напрямую обслуживается интерфейсным веб-сервером (nginx, Apache и т. Д.), Заголовок должен быть установлен последним. С другой стороны, если вы используете Django, чтобы позаботиться о таких вещах, как требование разрешения, прежде чем вы сможете загружать файлы, и вы не можете установить этот заголовок на веб-сервере, этот параметр будет полезно.

X-XSS-Protection: 1; mode=block

Некоторые браузеры имеют возможность блокировать контент, похожий на XSS-атаку . Они делают это, исследуя содержимое JavaScript в параметрах GET или POST страниц. Если в ответе сервера воспроизводится JavaScript, отображение страницы блокируется и вместо него отображается страница с ошибкой.

Заголовка X-XSS-Protection используется для управления работой фильтра XSS.

Чтобы включить фильтр XSS в браузере и заставить его всегда блокировать подозреваемые атаки XSS, вы можете установить заголовок . делает это для всех ответов, если для параметра установлено значение .X-XSS-Protection: 1; mode=block SecurityMiddleware SECURE_BROWSER_XSS_FILTER True

Предупреждение

XSS-фильтр браузера - полезная мера защиты, но на него нельзя полагаться исключительно. Он не может обнаружить все атаки XSS и поддерживается не всеми браузерами. Обязательно всегда проверяйте и очищайте все введенные значения, чтобы избежать XSS-атак.

Перенаправление SSL

Если ваш сайт предлагает как HTTP, так и HTTPS-соединения, большинство пользователей по умолчанию получит небезопасное соединение. Для большей безопасности вам следует перенаправить все HTTP-соединения на HTTPS.

Если вы установите для параметра SECURE_SSL_REDIRECT значение True , SecurityMiddleware будет постоянно перенаправлять (HTTP 301) все HTTP-соединения на HTTPS.

Заметка

По соображениям производительности лучше всего выполнять эти перенаправления за пределами Django, в интерфейсном балансировщике нагрузки или обратном прокси-сервере, таком как nginx . SECURE_SSL_REDIRECT предназначен для ситуаций развертывания, в которых этот сценарий невозможен.

Если параметр SECURE_SSL_HOST имеет значение, все перенаправления будут отправляться на этот хост вместо запрашивающего хоста.

Если определенные страницы вашего сайта должны оставаться доступными через HTTP без перенаправления на HTTPS, вы можете добавить регулярные выражения, соответствующие этим URL-адресам, в настройках SECURE_REDIRECT_EXEMPT (в виде списка).

Заметка

Если ваше развертывание находится за балансировщиком нагрузки или обратным прокси-сервером, и Django не может определить, является ли запрос уже защищенным или нет, вам может потребоваться настроить настройку SECURE_PROXY_SSL_HEADER .

Промежуточное ПО сеанса

класс SessionMiddleware

Включает поддержку сеанса. См. Документацию по сеансу .

Промежуточное ПО сайта

класс CurrentSiteMiddleware

Добавляет атрибут, site представляющий текущий сайт, к каждому HttpRequest входящему объекту . Смотрите документацию на сайтах .

Промежуточное ПО для аутентификации

класс AuthenticationMiddleware

Добавляет атрибут, user представляющий текущего вошедшего в систему пользователя, к каждому HttpRequest входящему объекту . См. Аутентификация в веб-запросах .

класс RemoteUserMiddleware

Промежуточное ПО, позволяющее использовать аутентификацию, предоставляемую веб-сервером. См. « Аутентификация с помощью REMOTE_USER» для получения подробной информации об использовании.

класс PersistentRemoteUserMiddleware

Промежуточное ПО для использования аутентификации, предоставляемой веб-сервером, если она включена только на странице входа. Подробнее об использовании см. Использование REMOTE_USER только для страниц входа .

Промежуточное ПО защиты CSRF

класс CsrfViewMiddleware

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

Промежуточное ПО X-Frame-Options

класс XFrameOptionsMiddleware

Простая защита от атак перехвата с помощью заголовка X-Frame-Options .

Порядок промежуточного ПО

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

  1. SecurityMiddleware

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

  2. UpdateCacheMiddleware

    Перед тем , что изменить заголовок Vary ( SessionMiddleware , GZipMiddleware , LocaleMiddleware ).

  3. GZipMiddleware

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

    После UpdateCacheMiddleware : изменить заголовок Vary .

  4. SessionMiddleware

    Перед любым промежуточным программным обеспечением, которое может вызвать исключение, чтобы вызвать представление ошибки (например, PermissionDenied ), если вы используете CSRF_USE_SESSIONS .

    После UpdateCacheMiddleware : изменить заголовок Vary .

  5. ConditionalGetMiddleware

    Перед любым промежуточным программным обеспечением, которое может изменять ответ (устанавливает заголовок ETag ).

    После GZipMiddleware этого он не вычисляет заголовок ETag для содержимого, сжатого gzip.

  6. LocaleMiddleware

    Должен быть первым, после SessionMiddleware (использует данные сеанса) и UpdateCacheMiddleware (изменяет заголовок Vary ).

  7. CommonMiddleware

    Перед любым промежуточным программным обеспечением, которое могло бы изменить ответ (оно устанавливает заголовок Content-Length ). Появившееся до этого промежуточное ПО, CommonMiddleware изменяющее ответ, должно сброситься Content-Length .

    В самом первом: перенаправляет когда APPEND_SLASH или PREPEND_WWW стоит True .

    После, SessionMiddleware если вы используете CSRF_USE_SESSIONS .

  8. CsrfViewMiddleware

    Прежде всего, промежуточное ПО, основанное на том, что CSRF-атаки уже отражены.

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

    После, SessionMiddleware если вы используете CSRF_USE_SESSIONS .

  9. AuthenticationMiddleware

    После SessionMiddleware : использует хранилище сеансов.

  10. MessageMiddleware

    После SessionMiddleware : можно использовать хранилище на основе сеанса.

  11. FetchFromCacheMiddleware

    После любого промежуточного программного обеспечения, которое изменяет заголовок Vary : этот заголовок используется для выбора значения для хеш-ключа кеша.

  12. FlatpageFallbackMiddleware

    Должно быть последним, потому что это последний вид промежуточного программного обеспечения.

  13. RedirectFallbackMiddleware

    Должно быть последним, потому что это последний вид промежуточного программного обеспечения.

Copyright ©2020 All rights reserved