GHSA-58C7-PX5V-82HH
Vulnerability from github – Published: 2021-04-06 17:28 – Updated: 2024-09-16 21:29django-registration is a user-registration application for Django.
Impact
The django-registration package provides tools for implementing user-account registration flows in the Django web framework. In django-registration prior to 3.1.2, the base user-account registration view did not properly apply filters to sensitive data, with the result that sensitive data could be included in error reports rather than removed automatically by Django.
Triggering this requires the following conditions:
- A site is using django-registration < 3.1.2
- The site has detailed error reports (such as Django's emailed error reports to site staff/developers) enabled
- A server-side error (HTTP 5xx) occurs during an attempt by a user to register an account
Under these conditions, recipients of the detailed error report will see all submitted data from the account-registration attempt, which may include the user's proposed credentials (such as a password).
Patches
As of version 3.1.2, django-registration properly applies Django's sensitive_post_parameters() decorator to the base user-registration view, which will cause all data from the HTTP request body to be filtered from detailed error reports in the event of a server-side crash during user account registration.
Note that as applied, this filters all HTTP request data from error reports. To selectively allow some fields but not others, see Django's own documentation (in references) and the notes below for how to apply sensitive_post_parameters() manually to a particular codebase's RegistrationView subclass(es).
Workarounds
Users who cannot upgrade quickly can apply the django.views.decorators.debug.sensitive_post_parameters() decorator to their own registration views. The decorator should be applied on the dispatch() method of the appropriate RegistrationView class, using Django's method_decorator() helper. For example:
from django.utils.decorators import method_decorator
from django.views.decorators.debug import sensitive_post_parameters
from django_registration.views import RegistrationView
class MyRegistrationView(RegistrationView):
"""
A RegistrationView subclass manually protected against sensitive information disclosure
in error reports.
"""
@method_decorator(sensitive_post_parameters())
def dispatch(self, *args, **kwargs):
return super().dispatch(*args, **kwargs)
References
- Django's documentation on error reporting in production
- How Django's sensitive-data filters work
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "django-registration"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-21416"
],
"database_specific": {
"cwe_ids": [
"CWE-201",
"CWE-209"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-01T21:03:08Z",
"nvd_published_at": "2021-04-01T22:15:00Z",
"severity": "LOW"
},
"details": "django-registration is a user-registration application for Django. \n\n### Impact\n\nThe django-registration package provides tools for implementing user-account registration flows in the Django web framework. In django-registration prior to 3.1.2, the base user-account registration view did not properly apply filters to sensitive data, with the result that sensitive data could be included in error reports rather than removed automatically by Django.\n\nTriggering this requires the following conditions:\n\n* A site is using django-registration \u003c 3.1.2\n* The site has detailed error reports (such as Django\u0027s [emailed error reports to site staff/developers](https://docs.djangoproject.com/en/3.1/howto/error-reporting/#email-reports)) enabled\n* A server-side error (HTTP 5xx) occurs during an attempt by a user to register an account\n\nUnder these conditions, recipients of the detailed error report will see all submitted data from the account-registration attempt, which may include the user\u0027s proposed credentials (such as a password).\n\n### Patches\n\nAs of version 3.1.2, django-registration properly applies Django\u0027s `sensitive_post_parameters()` decorator to the base user-registration view, which will cause all data from the HTTP request body to be filtered from detailed error reports in the event of a server-side crash during user account registration.\n\nNote that as applied, this filters *all* HTTP request data from error reports. To selectively allow some fields but not others, see Django\u0027s own documentation (in references) and the notes below for how to apply `sensitive_post_parameters()` manually to a particular codebase\u0027s `RegistrationView` subclass(es).\n\n### Workarounds\n\nUsers who cannot upgrade quickly can apply the `django.views.decorators.debug.sensitive_post_parameters()` decorator to their own registration views. The decorator should be applied on the `dispatch()` method of the appropriate `RegistrationView` class, using Django\u0027s `method_decorator()` helper. For example:\n\n```python\nfrom django.utils.decorators import method_decorator\nfrom django.views.decorators.debug import sensitive_post_parameters\n\nfrom django_registration.views import RegistrationView\n\nclass MyRegistrationView(RegistrationView):\n \"\"\"\n A RegistrationView subclass manually protected against sensitive information disclosure\n in error reports.\n\n \"\"\"\n @method_decorator(sensitive_post_parameters())\n def dispatch(self, *args, **kwargs):\n return super().dispatch(*args, **kwargs)\n```\n\n### References\n\n* Django\u0027s documentation on [error reporting in production](https://docs.djangoproject.com/en/3.1/howto/error-reporting/)\n* [How Django\u0027s sensitive-data filters work](https://docs.djangoproject.com/en/3.1/howto/error-reporting/#filtering-error-reports)",
"id": "GHSA-58c7-px5v-82hh",
"modified": "2024-09-16T21:29:06Z",
"published": "2021-04-06T17:28:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ubernostrum/django-registration/security/advisories/GHSA-58c7-px5v-82hh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21416"
},
{
"type": "WEB",
"url": "https://github.com/ubernostrum/django-registration/commit/2db0bb7ec35636ea46b07b146328b87b2cb13ca5"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/django-registration/PYSEC-2021-11.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/ubernostrum/django-registration"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Potential sensitive information disclosed in error reports"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.