Django의 보안 정책¶

보안 문제 보고¶

짧은 버전: 보안 문제는 security@djangoproject.com으로 이메일을 보내주세요.

Django의 버그는 대부분 ‘our public Trac instance’_에 보고되지만 보안 문제의 민감성때문에 이러한 방식으로 공개적으로 보고되지 않도록 요청합니다.

대신, Django에서 보안과 관련된 무언가를 발견했다고 생각되면 ``security@djangoproject.com``으로 이메일을 통해 문제에 대한 설명을 보내주십시오. 해당 주소로 발송된 메일은 보안팀 <https://www.djangoproject.com/foundation/teams/#security-team>`_에 도착합니다.

Once you’ve submitted an issue via email, you should receive an acknowledgment from a member of the security team within 3 working days. After that, the security team will begin their analysis. Depending on the action to be taken, you may receive followup emails. It can take several weeks before the security team comes to a conclusion. There is no need to chase the security team unless you discover new, relevant information. All reports aim to be resolved within the industry-standard 90 days. Confirmed vulnerabilities with a high severity level will be addressed promptly.

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, ["[email protected]"])
    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"],
            ["[email protected]"],
        )
        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.

Supported versions¶

Django팀은 언제든지 Django의 여러 버전에 대한 공식 보안 지원을 제공합니다.

• Django의 다음 주요 릴리스가 될 GitHub에서 호스팅되는 `main 개발 branch`_는 보안 지원을 받습니다. main 개발 branch에만 영향을 미치고 릴리스 버전에는 영향을 미치지 않는 보안 문제는 :ref:`공개 과정 <security-disclosure>`을 거치지 않고 공개적으로 수정됩니다.

• 최신 Django 릴리스 시리즈 2개는 보안 지원을 받습니다. 예를 들어, Django 1.5 릴리스로 이어지는 개발 주기 동안 Django 1.4 및 Django 1.3에 대한 지원이 제공됩니다. Django 1.5가 출시되면 Django 1.3의 보안 지원이 종료됩니다.

• 장기 지원 릴리스s는 지정된 기간 동안 보안 업데이트를 받게 됩니다.

보안상의 이유로 새 릴리스가 발행되면 함께 제공되는 알림에 영향을 받는 버전 목록이 제공됩니다. 이 목록은 지원되는 Django 버전으로만 구성되어 있습니다. 이전 버전도 영향을 받을 수 있지만 이를 확인하기 위한 조사는 하지 않으며 해당 버전에 대한 패치 또는 새 릴리스를 발행하지 않습니다.

Security issue severity levels¶

The severity level of a security vulnerability is determined by the attack type.

Severity levels are:

• High

  • 원격 코드 실행

  • SQL injection

• Moderate

  • 크로스 사이트 스크립팅 (XSS)

  • 크로스 사이트 요청 위조 (CSRF)

  • 서비스 거부 공격

  • 취약 인증

• Low

  • 민감한 데이터 노출

  • 손상된 세션 관리

  • 확인되지 않은 리디렉션/전달

  • 일반적이지 않은 구성 옵션이 필요한 문제

Django가 보안 문제를 공개하는 방법¶

비공개 토론에서 공개에 이르기까지 보안 문제를 처리하는 과정에는 여러 단계가 포함됩니다.

공개 약 1주일 전에 다음 두 가지 알림을 보냅니다.

First, we notify django-announce of the date and approximate time of the upcoming security release, as well as the severity of the issues. This is to aid organizations that need to ensure they have staff available to handle triaging our announcement and upgrade Django as needed.

둘째, 주로 운영 체제 공급업체 및 Django의 기타 배포자 people and organizations 목록을 알립니다. 이 이메일은 `Django’s release team`_의 PGP 키로 서명되었으며 다음으로 구성됩니다.

• 문제 및 영향을 받는 Django 버전에 대한 전체 설명.

• 문제를 해결하기 위해 취할 조치.

• Django에 적용될 패치가 있는 경우.

• Django 팀이 이러한 패치를 적용하고 새 릴리스를 발행하고 문제를 공개하는 날짜.

공개 당일 다음과 같은 조치를 취할 것입니다.:

1. 관련 패치를 Django 코드베이스에 적용합니다.

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. `the official Django development blog`_에 공개 항목을 게시하여 문제 및 해결 방법을 자세히 설명하고 관련 패치 및 새 릴리스를 가리키며 문제를 보고한 사람을 밝힙니다(보고자가 공개적으로 확인하려는 경우).

4. |django-announce|와 그 게시물로 연결되는 oss-securtiy@lists.openwall.com 메일링 리스트에 알림 게시.

보고된 문제가 특히 시간에 민감한 것으로 판단되는 경우 – 예를 들어 악용된 사례로 인해 – 사전 알림과 공개 상이의 시간이 상당히 단축될 수 있습니다.

또한 우리에게 보고된 문제가 Python/웹 생태계의 다른 프레임워크나 도구에 영향을 미친다고 믿을만한 이유가 있는 경우 해당 문제를 적절한 관리자와 개인적으로 논의할 수 있으며 우리의 공개와 해결 방법을 조정할 수 있습니다.

Django 팀은 또한 :doc:`archive of security issues disclosed in Django</releases/security>`를 유지 관리합니다.

사전 통지를 받는 사람¶

보안 문제에 대한 사전 알림을 받는 사람 및 조직의 전체 목록은 공개되지 않으며 앞으로도 공개되지 않을 것입니다.

또한 공개 전에 기밀 정보의 흐름을 더 잘 관리하기 위해 이 목록을 가능한 한 작게 유지하는 것을 목표로 합니다. 이와 같이 알림 목록은 단순히 Django 사용자 목록이 아닙니다. Django 사용자라는 것은 알림 목록에 포함될 충분한 이유가 아닙니다.

넓은 의미에서 보안 알림 수신자는 세 그룹으로 나뉩니다:

1. Operating-system vendors and other distributors of Django who provide a suitably-generic (i.e., not an individual’s personal email address) contact address for reporting issues with their Django package, or for general security reporting. In either case, such addresses must not forward to public mailing lists or bug trackers. Addresses which forward to the private email of an individual maintainer or security-response contact are acceptable, although private security trackers or security-response groups are strongly preferred.

2. 사례별로 이런한 알림에 응답하고 책임감 있게 조치를 취하는 데 전념하는 개별 패키지 관리자.

3. On a case-by-case basis, other entities who, in the judgment of the Django development team, need to be made aware of a pending security issue. Typically, membership in this group will consist of some of the largest and/or most likely to be severely impacted known users or distributors of Django, and will require a demonstrated ability to responsibly receive, keep confidential and act on these notifications.

알림 요청¶

귀하 또는 귀하의 조직이 위에 나열된 그룹 중 하나에 속한다면 ``security@djangoproject.com``으로 이메일을 보내 Django의 알림 목록에 추가 요청할 수 있습니다. “보안 알림 요청”이라는 제목을 사용하십시오.

요청에는 반드시 다음 정보가 포함되어야 합니다.:

• 귀하의 실명과 대표하는 조직의 이름(해당되는 경우) 및 해당 조직 내에서의 역할

• 귀하 또는 귀하의 조직이 위에 나열된 기준 세트 중 하나 이상을 충족시키는 방법에 대한 자세한 설명.

• A detailed explanation of why you are requesting security notifications. Again, please keep in mind that this is not simply a list for users of Django, and the overwhelming majority of users should subscribe to django-announce to receive advanced notice of when a security release will happen, without the details of the issues, rather than request detailed notifications.

• 알림 목록에 추가하고 싶은 이메일 주소.

• 해당 주소로 전송된 메일을 수신/검토할 사람에 대한 설명과 자동 조치에 관한 정보(예, 버그 추적기에 기밀 문제 제출).

• 개인의 경우, 필요에 따라 귀하로부터 받은 이메일을 확인하고 귀하에게 보낸 이메일을 암호화하는 데 사용할 수 있는 귀하의 주소와 연결된 공개 키의 ID입니다.

요청이 제출되면 Django 개발 팀에서 검토합니다. 30일 이내에 요청 결과 회신을 받게 됩니다.

또한 모든 개인 또는 조직에 대해 보안 알림을 받는 것은 Django 개발 팀의 단독 재량에 따라 부여된 권한이여 이 권한은 언제든지 취소될 수 있음을 명심하십시오.