Промежуточное ПО ¶
В этом документе объясняются все компоненты промежуточного программного обеспечения, поставляемые с Django. Для получения информации о том, как их использовать и как написать собственное промежуточное программное обеспечение, см. Руководство по использованию промежуточного программного обеспечения .
Доступное промежуточное ПО ¶
ПО промежуточного слоя кеширования ¶
-
класс
UpdateCacheMiddleware
¶
-
класс
FetchFromCacheMiddleware
¶
Включите кеширование всего сайта. Если они включены, каждая страница на базе Django будет кэшироваться до тех пор, пока это CACHE_MIDDLEWARE_SECONDS
определено параметром. См. Документацию по кешу .
«Обычное» промежуточное ПО ¶
-
класс
CommonMiddleware
¶
Добавляет несколько удобств для перфекционистов:
Запрещает доступ к пользовательским агентам в
DISALLOWED_USER_AGENTS
настройке, которая должна быть списком скомпилированных объектов регулярных выражений.Выступает URL перезапись на основе
APPEND_SLASH
иPREPEND_WWW
настроек.Если
APPEND_SLASH
есть,True
а исходный URL-адрес не заканчивается косой чертой и не найден в URLconf, то новый URL-адрес формируется путем добавления косой черты в конце. Если этот новый URL-адрес находится в URLconf, 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-адреса.При необходимости отдельные представления могут быть исключены из
APPEND_SLASH
поведения с помощьюno_append_slash()
декоратора:from django.views.decorators.common import no_append_slash @no_append_slash def sensitive_fbv(request, *args, **kwargs): """View to be excluded from APPEND_SLASH.""" return HttpResponse()
Изменено в Django 3.2:no_append_slash()
Добавлена поддержка декоратора.Устанавливает
Content-Length
заголовок для ответов без потоковой передачи.
-
CommonMiddleware.
response_redirect_class
¶
По умолчанию HttpResponsePermanentRedirect
. Создайте подкласс
CommonMiddleware
и переопределите атрибут, чтобы настроить перенаправления, создаваемые промежуточным программным обеспечением.
-
класс
BrokenLinkEmailsMiddleware
¶
- Отправляет электронные письма с уведомлением о неработающей ссылке
MANAGERS
(см. Отчет об ошибках ).
Промежуточное ПО GZip ¶
-
класс
GZipMiddleware
¶
Предупреждение
Исследователи безопасности недавно обнаружили, что когда GZipMiddleware
на веб-сайте используются методы сжатия (в том числе ), он может подвергнуться ряду возможных атак. Перед использованием GZipMiddleware
на своем сайте вы должны очень внимательно подумать, не подвержены ли вы этим атакам. Если у вас есть какие-либо сомнения относительно того, пострадали ли вы, вам следует избегать использования GZipMiddleware
. Дополнительные сведения см. В документе BREACH (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 ¶
Для сайтов, доступ к которым должен осуществляться только через HTTPS, вы можете указать современным браузерам отказаться от подключения к вашему доменному имени через небезопасное соединение (в течение определенного периода времени), установив заголовок «Strict-Transport-Security» . Это снижает вашу подверженность некоторым атакам типа "злоумышленник посередине" с удалением SSL (MITM).
SecurityMiddleware
установит этот заголовок для всех ответов HTTPS, если вы установите SECURE_HSTS_SECONDS
ненулевое целочисленное значение.
При включении HSTS рекомендуется сначала использовать небольшое значение для тестирования, например, в течение одного часа. Каждый раз, когда веб-браузер видит заголовок HSTS с вашего сайта, он будет отказываться осуществлять незащищенную связь (с использованием HTTP) с вашим доменом в течение заданного периода времени. После того, как вы подтвердите, что все ресурсы на вашем сайте надежно обслуживаются (т.е. HSTS ничего не сломал), рекомендуется увеличить это значение, чтобы нечастые посетители были защищены (обычно 31536000 секунд, т. Е. 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-адрес страницы, на которую указывает ссылка, в качестве источника перехода. Хотя это может быть полезно для некоторых целей - например, для определения того, кто ссылается на ваш сайт, - это также может вызвать проблемы с конфиденциальностью, сообщая одному сайту, что пользователь посещал другой сайт.
Некоторые браузеры могут принимать подсказки о том, следует ли отправлять Referer
заголовок HTTP, когда пользователь щелкает ссылку; эта подсказка предоставляется через заголовок 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
заголовка, поэтому полное отключение 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
заголовок для сжатого содержимого. -
Один из самых верхних, после
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
заголовок: этот заголовок используется для выбора значения для хэш-ключа кеша. -
Должен быть внизу, так как это последнее средство промежуточного слоя.
-
Должен быть внизу, так как это последнее средство промежуточного слоя.