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

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

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

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

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

Используя наборы запросов Django, результирующий 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.

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