Промежуточное ПО ¶
В этом документе описаны все компоненты промежуточного программного обеспечения, поставляемые с 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
¶
- Отправляет электронные письма с уведомлением о неработающей ссылке
MANAGERS
(см. Сообщение об ошибках ).
Промежуточное ПО 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
обеспечивает несколько улучшений безопасности для цикла запроса / ответа. Каждое улучшение можно включить или выключить независимо от настройки.
SECURE_BROWSER_XSS_FILTER
SECURE_CONTENT_TYPE_NOSNIFF
SECURE_HSTS_INCLUDE_SUBDOMAINS
SECURE_HSTS_PRELOAD
SECURE_HSTS_SECONDS
SECURE_REDIRECT_EXEMPT
SECURE_REFERRER_POLICY
SECURE_SSL_HOST
SECURE_SSL_REDIRECT
Строгая безопасность транспорта 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
.
Реферальная политика ¶
Браузеры используют заголовок 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:
-
Он должен быть довольно высок в списке, если вы планируете включить перенаправление SSL, поскольку оно позволяет избежать прохождения нескольких других ненужных промежуточных программ.
-
Перед тем , что изменить заголовок
Vary
(SessionMiddleware
,GZipMiddleware
,LocaleMiddleware
). -
Перед любым промежуточным программным обеспечением, которое могло бы изменить или использовать тело ответа.
После
UpdateCacheMiddleware
: изменить заголовокVary
. -
Перед любым промежуточным программным обеспечением, которое может вызвать исключение, чтобы вызвать представление ошибки (например,
PermissionDenied
), если вы используетеCSRF_USE_SESSIONS
.После
UpdateCacheMiddleware
: изменить заголовокVary
. -
Перед любым промежуточным программным обеспечением, которое может изменять ответ (устанавливает заголовок
ETag
).После
GZipMiddleware
этого он не вычисляет заголовокETag
для содержимого, сжатого gzip. -
Должен быть первым, после
SessionMiddleware
(использует данные сеанса) иUpdateCacheMiddleware
(изменяет заголовокVary
). -
Перед любым промежуточным программным обеспечением, которое могло бы изменить ответ (оно устанавливает заголовок
Content-Length
). Появившееся до этого промежуточное ПО,CommonMiddleware
изменяющее ответ, должно сброситьсяContent-Length
.В самом первом: перенаправляет когда
APPEND_SLASH
илиPREPEND_WWW
стоитTrue
.После,
SessionMiddleware
если вы используетеCSRF_USE_SESSIONS
. -
Прежде всего, промежуточное ПО, основанное на том, что CSRF-атаки уже отражены.
До
RemoteUserMiddleware
или любое другое промежуточное программное обеспечение проверки подлинности, которое могло бы установить соединение и, таким образом, активировать ротацию токена CSRF перед вызовом остальной части цепочки промежуточного программного обеспечения.После,
SessionMiddleware
если вы используетеCSRF_USE_SESSIONS
. -
После
SessionMiddleware
: использует хранилище сеансов. -
После
SessionMiddleware
: можно использовать хранилище на основе сеанса. -
После любого промежуточного программного обеспечения, которое изменяет заголовок
Vary
: этот заголовок используется для выбора значения для хеш-ключа кеша. -
Должно быть последним, потому что это последний вид промежуточного программного обеспечения.
-
Должно быть последним, потому что это последний вид промежуточного программного обеспечения.