Политики безопасности Django¶

Сообщение о проблемах безопасности¶

Краткая версия: пожалуйста, сообщайте о проблемах безопасности по электронной почте security@djangoproject.com.

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

Вместо этого, если вы считаете, что нашли что-то в Django, что имеет последствия для безопасности, пожалуйста, отправьте описание проблемы по электронной почте по адресу security@djangoproject.com. Почта, отправленная на этот адрес, попадает в команду безопасности <https://www.djangoproject.com/foundation/teams/#security-team>`_.

После отправки сообщения о проблеме по электронной почте вы должны получить подтверждение от сотрудника службы безопасности в течение 3 рабочих дней. После этого служба безопасности приступит к анализу. В зависимости от того, какие действия необходимо предпринять, вы можете получать дополнительные электронные письма. Может пройти несколько недель, прежде чем служба безопасности придет к какому-либо заключению. Нет необходимости обращаться к службе безопасности, если только вы не обнаружите новую, актуальную информацию. Все сообщения должны быть рассмотрены в течение стандартных для отрасли 90 дней. Подтвержденные уязвимости с high severity level будут устранены незамедлительно.

from django.core.mail import send_mail
from django.http import JsonResponse


def my_proof_of_concept(request):
    email = request.GET.get("email", "")
    send_mail("Email subject", "Email body", email, ["admin@example.com"])
    return JsonResponse(status=200)

from django import forms
from django.core.mail import send_mail
from django.http import JsonResponse


class EmailForm(forms.Form):
    email = forms.EmailField()


def my_proof_of_concept(request):
    form = EmailForm(request.GET)
    if form.is_valid():
        send_mail(
            "Email subject",
            "Email body",
            form.cleaned_data["email"],
            ["admin@example.com"],
        )
        return JsonResponse(status=200)
    return JsonResponse(form.errors, status=400)

from django.shortcuts import HttpResponse
from .models import MyModel


def my_proof_of_concept(request):
    query = request.GET.get("query", "")
    q = MyModel.objects.extra(select={"id": query})
    return HttpResponse(q.values())

Как Django оценивает отчет¶

Это критерии, используемые командой безопасности при оценке того, требуется ли для отчета обновление системы безопасности:

• Уязвимость находится в пределах supported version от Django.
• Уязвимость не зависит от действий, выполняемых вручную, которые основаны на коде, внешнем по отношению к Django. Сюда относятся действия, выполняемые разработчиком или сопровождающим проекта с использованием инструментов разработчика или интерфейса командной строки Django. Например, атаки, требующие выполнения команд управления с необычными или небезопасными параметрами, не подпадают под действие.
• Уязвимость применима к производственному приложению Django. Это означает, что для следующих сценариев не требуется обновление системы безопасности:
  • Эксплойты, которые влияют только на локальную разработку, например, при использовании runserver.
  • Эксплойты, которые не соответствуют рекомендациям по обеспечению безопасности, например, не обрабатывают вводимые пользователем данные. Другие примеры смотрите в нашем security documentation.
  • Эксплойты в коде, сгенерированном искусственным интеллектом, которые не соответствуют рекомендациям по обеспечению безопасности.

Команда безопасности может прийти к выводу, что источник уязвимости находится в стандартной библиотеке Python, и в этом случае репортеру будет предложено сообщить об уязвимости основной команде Python. Более подробную информацию смотрите в Python security guidelines.

Иногда для устранения уязвимости в популярном стороннем пакете может быть выпущен релиз системы безопасности. Эти отчеты должны поступать от разработчиков пакета.

Если вы не уверены, соответствует ли ваша находка этим критериям, пожалуйста, все равно сообщите об этом privately by emailing security@djangoproject.com. Служба безопасности рассмотрит ваш отчет и порекомендует правильный порядок действий.

Поддерживаемые версии¶

В любой момент времени команда Django обеспечивает официальную поддержку безопасности для нескольких версий Django:

• В main development branch, размещенном на GitHub, который станет следующим основным релизом Django, оказывается поддержка безопасности. Проблемы безопасности, которые затрагивают только основную ветвь разработки, а не какие-либо стабильные выпущенные версии, исправляются публично, не проходя через disclosure process.
• Две последние серии релизов Django получают поддержку безопасности. Например, во время цикла разработки, ведущего к выпуску Django 1.5, поддержка будет предоставляться для Django 1.4 и Django 1.3. После выхода Django 1.5 поддержка безопасности Django 1.3 будет прекращена.
• Long-term support releases будет получать обновления безопасности в течение указанного периода.

Когда новые релизы выпускаются по соображениям безопасности, сопроводительное уведомление будет включать список затронутых версий. Этот список состоит исключительно из поддерживаемых версий Django: более старые версии также могут быть затронуты, но мы не проводим расследования, чтобы определить это, и не будем выпускать патчи или новые релизы для этих версий.

Уровни серьезности проблем безопасности¶

Уровень серьезности уязвимости в системе безопасности определяется типом атаки.

Уровни серьезности следующие:

• Высокий
  • Удаленное выполнение кода
  • SQL-инъекция
• Умеренный
  • Межсайтовый скриптинг (XSS)
  • Подделка межсайтового запроса (CSRF)
  • Атаки на отказ в обслуживании
  • Сломанная аутентификация
• Низкий уровень
  • Раскрытие чувствительных данных
  • Нарушенное управление сеансами
  • Недействительные перенаправления/переадресации
  • Проблемы, требующие необычного варианта конфигурации

Как Django раскрывает проблемы безопасности¶

Наш процесс перехода от частного обсуждения проблемы безопасности к ее обнародованию включает в себя несколько этапов.

Примерно за неделю до обнародования информации мы отправляем два уведомления:

Во-первых, мы уведомляем |django-анонсируем| о дате и приблизительном времени предстоящего выпуска системы безопасности, а также о серьезности проблем. Это делается для того, чтобы помочь организациям, которым необходимо обеспечить наличие персонала для обработки нашего объявления и обновления Django по мере необходимости.

Во-вторых, мы уведомляем список people and organizations, состоящий в основном из поставщиков операционных систем и других распространителей Django. Это письмо подписано PGP-ключом кого-то из команды выпуска Django и состоит из:

• Полное описание проблемы и затронутых версий Django.
• Шаги, которые мы предпримем для устранения проблемы.
• Патч(и), если таковые имеются, которые будут применены к Django.
• Дата, когда команда Django применит эти исправления, выпустит новые релизы и публично раскроет проблему.

В день раскрытия информации мы предпримем следующие шаги:

1. Примените соответствующий патч(и) к кодовой базе Django.
2. Выпустить соответствующий релиз(ы), разместив новые пакеты на Python Package Index и на djangoproject.com website, и пометив новый релиз(ы) в git-репозитории Django.
3. Опубликовать публичную запись в официальном блоге разработчиков Django, подробно описав проблему и ее решение, указав на соответствующие патчи и новые релизы, и поблагодарив автора проблемы (если он желает быть публично идентифицированным).
4. Опубликуйте уведомление в списках рассылки django-announce и oss-security@lists.openwall.com со ссылкой на запись в блоге.

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

Кроме того, если у нас есть основания полагать, что проблема, о которой нам сообщили, затрагивает другие фреймворки или инструменты в экосистеме Python/web, мы можем в частном порядке связаться и обсудить эти проблемы с соответствующими сопровождающими, а также скоординировать наше раскрытие и решение с ними.

Команда Django также поддерживает archive of security issues disclosed in Django.

Кто получает предварительное уведомление¶

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

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

В широком смысле получатели уведомлений о безопасности делятся на три группы:

1. Поставщики операционных систем и другие распространители Django, которые предоставляют достаточно общий (т.е. не личный адрес электронной почты человека) контактный адрес для сообщений о проблемах с их пакетом Django, или для общих сообщений о безопасности. В любом случае, такие адреса не должны пересылаться в публичные списки рассылки или баг-трекеры. Адреса, которые перенаправляют на личную почту отдельного сопровождающего или контактного лица security-response, приемлемы, хотя частные трекеры безопасности или группы security-response являются предпочтительными.
2. В каждом конкретном случае, отдельные сопровождающие пакетов, которые продемонстрировали приверженность реагированию и ответственному отношению к этим уведомлениям.
3. В каждом конкретном случае, другие организации, которые, по мнению команды разработчиков Django, должны быть проинформированы о предстоящей проблеме безопасности. Как правило, в эту группу входят крупнейшие и/или наиболее подверженные серьезному воздействию известные пользователи или распространители Django, и от них требуется продемонстрировать способность ответственно получать, хранить конфиденциальность и действовать в соответствии с этими уведомлениями.

Запрос уведомлений¶

Если вы считаете, что вы или организация, которую вы уполномочены представлять, попадаете в одну из перечисленных выше групп, вы можете попросить добавить вас в список уведомлений Django, написав по электронной почте security@djangoproject.com. Пожалуйста, используйте тему письма «Запрос на уведомление о безопасности».

Ваш запрос должен включать следующую информацию:

• Ваше полное, настоящее имя и название организации, которую вы представляете, если это применимо, а также ваша роль в этой организации.
• Подробное объяснение того, как вы или ваша организация соответствуете хотя бы одному из перечисленных выше критериев.
• Подробное объяснение того, почему вы запрашиваете уведомления о безопасности. Опять же, пожалуйста, помните, что это не просто список для пользователей Django, и подавляющему большинству пользователей следует подписаться на django-announce, чтобы получать предварительное уведомление о том, когда будет выпущен релиз безопасности, без подробностей проблем, а не запрашивать подробные уведомления.
• Адрес электронной почты, который вы хотели бы добавить в наш список уведомлений.
• Объяснение того, кто будет получать/просматривать почту, отправленную на этот адрес, а также информация о любых автоматических действиях, которые будут предприняты (например, подача конфиденциальной проблемы в систему отслеживания ошибок).
• Для физических лиц - идентификатор открытого ключа, связанного с вашим адресом, который может использоваться для проверки полученной от вас электронной почты и шифрования отправленной вам электронной почты, по мере необходимости.

После отправки ваш запрос будет рассмотрен командой разработчиков Django; вы получите ответ с уведомлением о результате рассмотрения вашего запроса в течение 30 дней.

Также следует помнить, что для любого человека или организации получение уведомлений о безопасности является привилегией, предоставляемой исключительно по усмотрению команды разработчиков Django, и что эта привилегия может быть отозвана в любой момент, с объяснением или без объяснения причин.