Безопасность в Django

Этот документ представляет собой обзор функций безопасности Django. Он включает в себя советы по обеспечению безопасности сайта на Django.

Крест скриптинг (XSS) Защита

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

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

Шаблоны Django избегают определенных символов, которые особенно опасны для HTML. Хотя это защищает пользователей от большинства злонамеренных действий, это не совсем надежно. Например, он не защитит следующее:

<style class={{ var }}>...</style>

Если varустановлено значение , это может привести к несанкционированному выполнению JavaScript, в зависимости от того, как браузер отображает несовершенный HTML. (Цитирование значения атрибута исправит этот случай.)'class1 onmouseover=javascript:func()'

Также важно проявлять особую осторожность при использовании is_safeс настраиваемыми тегами safeшаблона, тегом шаблона mark_safeи когда автоэскейп отключен.

Кроме того, если вы используете систему шаблонов для вывода чего-либо, кроме HTML, могут быть совершенно отдельные символы и слова, требующие экранирования.

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

Защита от подделки межсайтовых запросов (CSRF)

Атаки CSRF позволяют злоумышленнику выполнять действия, используя учетные данные другого пользователя, без ведома или согласия этого пользователя.

Django имеет встроенную защиту от большинства типов CSRF-атак, если вы включили ее и использовали там, где это необходимо. Однако, как и у любого метода смягчения последствий, есть ограничения. Например, можно отключить модуль CSRF глобально или для определенных представлений. Вам следует делать это только в том случае, если вы знаете, что делаете. Существуют и другие ограничения, если у вашего сайта есть субдомены, которые находятся вне вашего контроля.

Защита CSRF работает , проверяя секрет в каждом запросе POST. Это гарантирует, что злоумышленник не сможет «воспроизвести» POST формы на вашем веб-сайте и заставить другого вошедшего в систему пользователя невольно отправить эту форму. Злоумышленник должен знать секрет, зависящий от пользователя (с помощью файла cookie).

При развертывании с HTTPS , CsrfViewMiddlewareбудет проверять , что HTTP Referer заголовок устанавливаются в URL на то же происхождение (включая подобласти и порт). Поскольку протокол HTTPS обеспечивает дополнительную безопасность, необходимо убедиться, что соединения используют протокол HTTPS там, где он доступен, путем пересылки небезопасных запросов на соединение и использования HSTS для поддерживаемых браузеров.

Будьте очень осторожны с маркировкой видов с помощью csrf_exemptдекоратора, если это не абсолютно необходимо.

Защита от SQL-инъекций

SQL-инъекция - это тип атаки, при которой злоумышленник может выполнить произвольный код SQL в базе данных. Это может привести к удалению записей или утечке данных.

Наборы запросов Django защищены от SQL-инъекций, поскольку их запросы построены с использованием параметризации запросов. Код SQL запроса определяется отдельно от параметров запроса. Поскольку параметры могут быть предоставлены пользователем и, следовательно, небезопасны, они экранируются базовым драйвером базы данных.

Django также дает разработчикам возможность писать необработанные запросы или выполнять собственный sql . Эти возможности следует использовать с осторожностью, и вы всегда должны быть осторожны, чтобы должным образом избежать любых параметров, которыми может управлять пользователь. Кроме того, следует соблюдать осторожность при использовании extra() и RawSQL.

Защита от кликджекинга

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

Джанго содержит защиту ClickJacking в форме , которая в поддерживающем браузере может предотвратить сайт от визуализации внутри фрейма. Можно отключить защиту для каждого просмотра или настроить точное значение отправляемого заголовка.X-Frame-Options middleware

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

SSL / HTTPS

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

Если вам нужна защита, которую обеспечивает HTTPS, и вы включили ее на своем сервере, вам могут потребоваться некоторые дополнительные шаги:

  • При необходимости настройте SECURE_PROXY_SSL_HEADER, убедившись, что вы полностью поняли содержащиеся в нем предупреждения. Невыполнение этого требования может привести к уязвимости CSRF, и неправильное выполнение этого также может быть опасным!

  • Установите SECURE_SSL_REDIRECTзначение True, чтобы запросы через HTTP перенаправлялись на HTTPS.

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

  • Используйте «безопасные» файлы cookie.

    Если браузер изначально подключается через HTTP, который используется по умолчанию для большинства браузеров, возможна утечка существующих файлов cookie. По этой причине, вы должны установить свои SESSION_COOKIE_SECUREи CSRF_COOKIE_SECUREнастройки в True. Это указывает браузеру отправлять эти файлы cookie только через HTTPS-соединения. Обратите внимание, что это будет означать, что сеансы не будут работать через HTTP, а защита CSRF предотвратит прием любых данных POST через HTTP (что будет нормально, если вы перенаправляете весь HTTP-трафик на HTTPS).

  • Используйте HTTP Strict Transport Security (HSTS)

    HSTS - это HTTP-заголовок, который сообщает браузеру, что все будущие подключения к определенному сайту всегда должны использовать HTTPS. В сочетании с перенаправлением запросов через HTTP на HTTPS это гарантирует, что соединения всегда будут пользоваться дополнительной безопасностью SSL при условии, что произошло одно успешное соединение. HSTS можно настроить с помощью SECURE_HSTS_SECONDS, SECURE_HSTS_INCLUDE_SUBDOMAINSи SECURE_HSTS_PRELOAD, либо на веб-сервере.

Проверка заголовка хоста

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

Поскольку даже кажущиеся безопасными конфигурации веб-сервера подвержены поддельным Hostзаголовкам, Django проверяет Hostзаголовки на соответствие ALLOWED_HOSTSпараметрам в django.http.HttpRequest.get_host()методе.

Эта проверка применяется только через get_host(); если ваш код обращается к Hostзаголовку напрямую от request.METAвас, вы обходите эту защиту.

Подробнее см. Полную ALLOWED_HOSTSдокументацию.

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

Предыдущие версии этого документа рекомендовали настроить ваш веб-сервер, чтобы он проверял входящие Hostзаголовки HTTP . Хотя это по-прежнему рекомендуется, на многих распространенных веб-серверах конфигурация, которая, кажется, проверяет Hostзаголовок, на самом деле может этого не делать. Например, даже если Apache настроен таким образом, что ваш сайт Django обслуживается с виртуального хоста, отличного от установленного по умолчанию, ServerNameдля HTTP-запроса все еще возможно сопоставление этого виртуального хоста и предоставление поддельного Hostзаголовка. Таким образом, Django теперь требует, чтобы вы указали ALLOWED_HOSTSявно, а не полагались на конфигурацию веб-сервера.

Кроме того, Django требует, чтобы вы явно включили поддержку X-Forwarded-Hostзаголовка (через USE_X_FORWARDED_HOSTпараметр), если этого требует ваша конфигурация.

Политика реферера ¶

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

Безопасность сеанса

Подобно ограничениям CSRF, требующим, чтобы сайт был развернут таким образом, чтобы недоверенные пользователи не имели доступа к каким-либо поддоменам, django.contrib.sessionsтакже есть ограничения. См. Подробности в разделе руководства по теме сеанса, посвященном безопасности .

Загружаемый пользователем контент

Примечание

Рассмотрите возможность обслуживания статических файлов из облачной службы или CDN, чтобы избежать некоторых из этих проблем.

  • Если ваш сайт принимает загрузку файлов, настоятельно рекомендуется ограничить эти загрузки в конфигурации вашего веб-сервера до разумного размера, чтобы предотвратить атаки типа «отказ в обслуживании» (DOS). В Apache это можно легко установить с помощью директивы LimitRequestBody .

  • Если вы обслуживаете свои собственные статические файлы, убедитесь, что такие обработчики, как Apache mod_php, которые будут выполнять статические файлы как код, отключены. Вы не хотите, чтобы пользователи могли выполнять произвольный код, загружая и запрашивая специально созданный файл.

  • Обработка загрузки мультимедиа в Django создает некоторые уязвимости, когда этот носитель обслуживается способами, не соответствующими рекомендациям по безопасности. В частности, файл HTML может быть загружен как изображение, если этот файл содержит допустимый заголовок PNG, за которым следует вредоносный HTML. Этот файл пройдет проверку библиотеки, которую Django использует для ImageFieldобработки изображений (Pillow). Когда этот файл впоследствии отображается для пользователя, он может отображаться как HTML в зависимости от типа и конфигурации вашего веб-сервера.

    На уровне фреймворка не существует надежного технического решения для безопасной проверки всего содержимого загруженных пользователем файлов, однако есть некоторые другие шаги, которые вы можете предпринять для смягчения этих атак:

    1. Один класс атак можно предотвратить, всегда обслуживая загруженный пользователем контент из отдельного домена верхнего или второго уровня. Это предотвращает любой эксплойт, заблокированный политикой защиты одного и того же происхождения, такой как межсайтовый скриптинг. Например, если ваш сайт работает example.com, вам нужно будет обслуживать загруженный контент ( MEDIA_URLнастройку) из чего-то вроде usercontent-example.com. Это не достаточно , чтобы служить содержание от субдомен usercontent.example.com.
    2. Помимо этого, приложения могут определять список допустимых расширений файлов для загружаемых пользователем файлов и настраивать веб-сервер для обслуживания только таких файлов.

Дополнительные темы безопасности

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

  • Убедитесь, что ваш код Python находится за пределами корня веб-сервера. Это гарантирует, что ваш код Python случайно не будет представлен в виде обычного текста (или случайно выполнен).
  • Будьте осторожны с любыми файлами, загруженными пользователем .
  • Django не ограничивает запросы на аутентификацию пользователей. Чтобы защитить систему аутентификации от атак методом перебора, вы можете рассмотреть возможность развертывания подключаемого модуля Django или модуля веб-сервера для регулирования этих запросов.
  • Держи SECRET_KEYв секрете.
  • Рекомендуется ограничить доступность вашей системы кэширования и базы данных с помощью брандмауэра.
  • Взгляните на список 10 лучших проектов Open Web Application Security Project (OWASP), который определяет некоторые распространенные уязвимости в веб-приложениях. Хотя в Django есть инструменты для решения некоторых проблем, другие проблемы необходимо учитывать при разработке вашего проекта.
  • Mozilla обсуждает различные темы, касающиеся веб-безопасности . На их страницах также приведены принципы безопасности, применимые к любой системе.

Copyright ©2021 All rights reserved