Reporting security issues¶

Short version: please report security issues by emailing security@djangoproject.com.

Most normal bugs in Django are reported to our public Trac instance, but due to the sensitive nature of security issues, we ask that they not be publicly reported in this fashion.

Instead, if you believe you’ve found something in Django which has security implications, please send a description of the issue via email to security@djangoproject.com. Mail sent to that address reaches the security team.

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

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())

How does Django evaluate a report¶

These are criteria used by the security team when evaluating whether a report requires a security release:

• The vulnerability is within a supported version of Django.

• The vulnerability does not depend on manual actions that rely on code external to Django. This includes actions performed by a project’s developer or maintainer using developer tools or the Django CLI. For example, attacks that require running management commands with uncommon or insecure options do not qualify.

• The vulnerability applies to a production-grade Django application. This means the following scenarios do not require a security release:

  • Exploits that only affect local development, for example when using runserver.

  • Exploits which fail to follow security best practices, such as failure to sanitize user input. For other examples, see our security documentation.

  • Exploits in AI generated code that do not adhere to security best practices.

The security team may conclude that the source of the vulnerability is within the Python standard library, in which case the reporter will be asked to report the vulnerability to the Python core team. For further details see the Python security guidelines.

On occasion, a security release may be issued to help resolve a security vulnerability within a popular third-party package. These reports should come from the package maintainers.

If you are unsure whether your finding meets these criteria, please still report it privately by emailing security@djangoproject.com. The security team will review your report and recommend the correct course of action.

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

At any given time, the Django team provides official security поддержка several versions of Django:

• The main development branch, hosted on GitHub, which will become the next major release of Django, receives security support. Security issues that only affect the main development branch and not any stable released versions are fixed in public without going through the disclosure process.

• The two most recent Django release series receive security support. For example, during the development cycle leading to the release of Django 1.5, support will be provided for Django 1.4 and Django 1.3. Upon the release of Django 1.5, Django 1.3’s security support will end.

• Long-term support releases will receive security updates for a specified period.

When new releases are issued for security reasons, the accompanying notice will include a list of affected versions. This list is comprised solely of supported versions of Django: older versions may also be affected, but we do not investigate to determine that, and will not issue patches or new releases for those versions.

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

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

Уровни серьезности:

• Высокий

  • Удаленное выполнение кода

  • SQL-инъекция

• Средний

  • Межсайтовый скриптинг (XSS)

  • Подделка межсайтовых запросов (CSRF)

  • Атаки типа «отказ в обслуживании»

  • Нарушенная аутентификация

• Низкий

  • Раскрытие конфиденциальных данных

  • Нарушенное управление сеансами

  • Непроверенные перенаправления

  • Проблемы, требующие нестандартной опции конфигурации

How Django discloses security issues¶

Our process for taking a security issue from private discussion to public disclosure involves multiple steps.

Approximately one week before public disclosure, we send two notifications:

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

Second, we notify a list of people and organizations, primarily composed of operating-system vendors and other distributors of Django. This email is signed with the PGP key of someone from Django’s release team and consists of:

• A full description of the issue and the affected versions of Django.

• The steps we will be taking to remedy the issue.

• The patch(es), if any, that will be applied to Django.

• The date on which the Django team will apply these patches, issue new releases and publicly disclose the issue.

On the day of disclosure, we will take the following steps:

1. Apply the relevant patch(es) to Django’s codebase.

2. Issue the relevant release(s), by placing new packages on the Python Package Index and on the djangoproject.com website, and tagging the new release(s) in Django’s git repository.

3. Post a public entry on the official Django development blog, describing the issue and its resolution in detail, pointing to the relevant patches and new releases, and crediting the reporter of the issue (if the reporter wishes to be publicly identified).

4. Post a notice to the django-announce and oss-security@lists.openwall.com mailing lists that links to the blog post.

If a reported issue is believed to be particularly time-sensitive – due to a known exploit in the wild, for example – the time between advance notification and public disclosure may be shortened considerably.

Additionally, if we have reason to believe that an issue reported to us affects other frameworks or tools in the Python/web ecosystem, we may privately contact and discuss those issues with the appropriate maintainers, and coordinate our own disclosure and resolution with theirs.

The Django team also maintains an archive of security issues disclosed in Django.

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

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

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

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

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

2. В индивидуальном порядке отдельные сопровождающие пакетов, которые продемонстрировали приверженность реагированию и ответственным действиям по этим уведомлениям.

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

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

If you believe that you, or an organization you are authorized to represent, fall into one of the groups listed above, you can ask to be added to Django’s notification list by emailing security@djangoproject.com. Please use the subject line «Security notification request».

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

• Ваше полное настоящее имя и название организации, которую вы представляете, если применимо, а также вашу роль в этой организации.

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

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

• Адрес электронной почты, который вы хотели бы добавить в наш список уведомлений.

• Объяснение того, кто будет получать/просматривать почту, отправленную на этот адрес, а также информацию о любых автоматических действиях, которые будут предприняты (например, регистрация конфиденциальной проблемы в баг-трекере).

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

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

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