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

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

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

Использование шаблонов Django защищает вас от большинства XSS-атак. Тем не менее, важно понимать, какие меры защиты он обеспечивает и его ограничения.

Шаблоны Django избегают определенных символов, которые особенно опасны для HTML. Хотя это защищает пользователей от большинства вредоносных входных данных, это не совсем надежно. Например, он не защитит следующее:

<style class={{ var }}>...</style>

Если var установлено значение , это может привести к несанкционированному выполнению JavaScript, в зависимости от того, как браузер отображает несовершенный HTML. (Указание значения атрибута исправит этот случай.)'class1 onmouseover=javascript:func()'

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

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

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

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

Политика реферера ¶

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

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

Подобно ограничениям CSRF, требующим, чтобы сайт был развернут таким образом, чтобы недоверенные пользователи не имели доступа к каким-либо поддоменам, django.contrib.sessions также есть ограничения. См. Подробности в разделе руководства по теме сеанса, посвященном безопасности .

Пользовательский контент ¶

• Если ваш сайт допускает загрузку файлов, настоятельно рекомендуется ограничить эти загрузки в конфигурации вашего веб-сервера до разумного размера, чтобы предотвратить атаки типа «отказ в обслуживании» (DOS). В Apache это можно легко установить с помощью директивы LimitRequestBody .

• Если вы обслуживаете свои собственные статические файлы, убедитесь, что такие обработчики, как Apache mod_php , которые будут выполнять статические файлы как код, отключены. Вы не хотите, чтобы пользователи могли выполнять произвольный код, загружая и запрашивая специально созданный файл.

• Обработка загрузки мультимедиа в 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 есть инструменты для решения некоторых проблем, другие проблемы необходимо учитывать при разработке вашего проекта.
• Mozilla обсуждает различные темы, касающиеся веб-безопасности . На их страницах также приведены принципы безопасности, применимые к любой системе.