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

В данном документе представлен обзор функций безопасности Django. Он содержит рекомендации по обеспечению безопасности сайта, работающего на Django.

Защита от межсайтовых сценариев (XSS)

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

Использование шаблонов Django защищает вас от большинства атак XSS. Тем не менее, важно понять, какую защиту они обеспечивают, и ее ограничения.

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

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

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

Также важно проявлять особую осторожность при использовании 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.

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

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

Django содержит защиту от кликджекинга в виде 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, или на веб-сервере.

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

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

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

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

Для получения более подробной информации см. полную документацию ALLOWED_HOSTS.

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

Политика переадресации

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

Политика открытия кросс-доменных окон

Заголовок политики открытия кросс-доменных окон (COOP) позволяет браузерам изолировать окно верхнего уровня от других документов, помещая их в разные группы контекстов, чтобы они не могли напрямую взаимодействовать с окном верхнего уровня. Если документ, защищённый COOP, открывает всплывающее окно с другим домен, свойство window.opener всплывающего окна будет null. COOP защищает от атак с другого домена. Подробнее см. в разделе политики открытия кросс-доменных окон в справочнике по middleware безопасности.

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

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

Безопасность загружаемого пользователем контента

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

• Обработка загрузки медиафайлов 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 и SECRET_KEY_FALLBACKS (если используется) в секрете.
• Рекомендуется ограничить доступ к вашей системе кэширования и базе данных с помощью брандмауэра.
• Ознакомьтесь со списком 10 наиболее распространённых уязвимостей веб-приложений проекта Open Web Application Security Project (OWASP) Top 10. Хотя Django имеет инструменты для решения некоторых проблем, другие проблемы необходимо учитывать при проектировании вашего проекта.
• Mozilla обсуждает различные темы, связанные с безопасностью веб-приложений. Их страницы также включают принципы безопасности, которые применимы к любой системе.