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

В этом документе объясняются все компоненты промежуточного программного обеспечения, поставляемые с 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

Промежуточное ПО 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Обеспечивает ряд усовершенствований безопасности цикла запрос / ответ. Каждый из них может быть независимо включен или отключен с помощью настройки.

Строгая безопасность транспорта 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=blockSecurityMiddlewareSECURE_BROWSER_XSS_FILTERTrue

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

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заголовок для сжатого содержимого.

  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

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

СОДЕРЖАНИЕ

Просматривать

Вы здесь:

Django Docs

Copyright ©2021 All rights reserved