Безопасность в Django

Всегда очищайте вводимые пользователем данные

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

Защита от межсайтового скриптинга (XSS)

XSS-атаки позволяют пользователю внедрять клиентские скрипты в браузеры других пользователей. Обычно это достигается сохранением вредоносных скриптов в базе данных, откуда они извлекаются и отображаются другим пользователям, или побуждением пользователей перейти по ссылке, из-за чего браузер пользователя выполняет JavaScript-код атакующего. Однако источником XSS-атак могут стать любые ненадежные данные, например файлы cookie или веб-службы, если эти данные недостаточно очищены перед включением в страницу.

Использование шаблонов 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 с атрибутом secure.

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

Кроме того, если ваша конфигурация требует поддержки заголовка X-Forwarded-Host, ее необходимо явно включить с помощью параметра USE_X_FORWARDED_HOST.

Политика Referrer

Браузеры используют заголовок Referer, чтобы сообщить сайту, как на него попали пользователи. Задав политику Referrer, можно защитить конфиденциальность пользователей, ограничив обстоятельства, при которых устанавливается заголовок Referer. Подробнее см. раздел о политике Referrer в справочнике по промежуточному ПО безопасности.

Политика изоляции окон от источников другого происхождения

Заголовок Cross-Origin Opener Policy (COOP) позволяет браузерам изолировать окно верхнего уровня от других документов, помещая их в разные группы контекстов, чтобы они не могли напрямую взаимодействовать с окном верхнего уровня. Если документ, защищенный COOP, открывает всплывающее окно с другим источником, свойство window.opener этого окна будет равно null. COOP защищает от атак с других источников. Подробнее см. раздел о политике Cross-Origin Opener Policy в справочнике по промежуточному ПО безопасности.

Безопасность сеансов

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

Политика безопасности содержимого

Content Security Policy (CSP) — это механизм безопасности браузера, который помогает защищать веб-приложения от таких атак, как межсайтовый скриптинг (XSS) и внедрение другого содержимого.

CSP позволяет веб-приложениям определять доверенные источники содержимого и указывать браузеру загружать, выполнять или отображать ресурсы только из этих источников. Таким образом, создается список разрешенных источников содержимого, что снижает риск выполнения вредоносного кода.

К основным преимуществам включения CSP относятся:

1. Снижение риска XSS-атак за счет блокировки встроенных скриптов и ограничения загрузки внешних скриптов.
2. Контроль внешних ресурсов, которые могут загружаться (например, изображений, шрифтов и таблиц стилей).
3. Предотвращение нежелательного встраивания сайта во фрейм для защиты от кликджекинга.
4. Отправка отчетов о нарушениях на указанный адрес, что позволяет отслеживать их и устранять проблемы.

Инструкции по настройке см. в документации «Использование CSP», а подробную информацию о директивах и параметрах — в обзоре CSP.

Дополнительные вопросы безопасности

Django обеспечивает хорошую защиту из коробки, однако важно правильно развернуть приложение и использовать средства защиты веб-сервера, операционной системы и других компонентов.

• Убедитесь, что код Python находится за пределами корневого каталога веб-сервера. Это позволит избежать случайной раздачи кода Python в виде обычного текста (или его случайного выполнения).
• Соблюдайте осторожность при работе с файлами, загружаемыми пользователями.
• Django не ограничивает частоту запросов на аутентификацию пользователей. Чтобы защититься от перебора учетных данных, можно установить плагин Django или модуль веб-сервера, ограничивающий частоту таких запросов.
• Храните в секрете SECRET_KEY и, если используется, SECRET_KEY_FALLBACKS.
• Рекомендуется ограничить доступ к системе кэширования и базе данных с помощью брандмауэра.
• Ознакомьтесь со списком 10 главных угроз проекта Open Web Application Security Project (OWASP), в котором перечислены распространенные уязвимости веб-приложений. Django предоставляет инструменты для устранения некоторых из этих проблем, но другие необходимо учитывать при проектировании приложения.
• Mozilla рассматривает различные вопросы, связанные с безопасностью веб-приложений. На этих страницах также изложены принципы безопасности, применимые к любой системе.