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