Безопасность в 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 на ваш сайт и заставить другого вошедшего в систему пользователя без ведома отправить эту форму. Злоумышленник должен знать секрет, который является специфическим для пользователя (используя куки).

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

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

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

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

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

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

Защита от Clickjacking

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

Django содержит защиту от 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.

• Используйте «защищенные» куки.

  Если браузер первоначально подключается по протоколу HTTP, что является стандартным для большинства браузеров, существующие куки могут быть раскрыты. Поэтому вы должны установить свои настройки SESSION_COOKIE_SECURE и CSRF_COOKIE_SECURE на True. Это указывает браузеру отправлять эти куки только по 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 использует заголовок 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), если ваша конфигурация этого требует.

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

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