Безопасность в 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.

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

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

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.

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

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

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

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