Безопасность в 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 будет корректно экранирован драйвером базы данных. Однако Django также предоставляет разработчикам возможность написания сырых запросов или выполнения пользовательского SQL. Эти возможности следует использовать с осторожностью, и вы всегда должны тщательно экранировать любые параметры, которые могут контролироваться пользователем. Кроме того, следует проявлять осторожность при использовании extra() и RawSQL.

Защита от Clickjacking

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

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

Этот 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 или на веб-сервере.

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