In accordance with our security release policy, the Django team is issuing releases for Django 6.0.6 and Django 5.2.15. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as possible.
django.http.HttpRequest.get_signed_cookieget_signed_cookie() derived the signing salt by concatenating the cookie name (key) and salt arguments. When distinct name and salt pairs produced the same concatenation, cookies could be accepted
in a context different from the one where they were signed.
Cookies are now signed with an unambiguous salt derivation. For backwards compatibility, cookies signed by older Django versions are accepted until Django 7.0.
This issue has severity "low" according to the Django security policy.
Thanks to Peng Zhou for the report.
STARTTLS in the SMTP backendWhen using EMAIL_USE_TLS, a failed STARTTLS handshake could leave a partially-initialized connection that would subsequently be reused for sending email without encryption. This can occur with fail_silently=True, as used by send_mail() and BrokenLinkEmailsMiddleware, among others. Connections configured with EMAIL_USE_SSL are not affected.
This issue has severity "low" according to the Django security policy.
Thanks to Kasper Dupont for the report.
Cache-Control directives in UpdateCacheMiddlewaredjango.middleware.cache.UpdateCacheMiddleware and django.views.decorators.cache.cache_page decorator incorrectly cached responses marked with private Cache-Control directives when using mixed or uppercase values (e.g. Private).
The django.views.decorators.cache.cache_control decorator and django.utils.cache.patch_cache_control() function were not affected, since they normalize directives to lowercase. This issue only affects responses where Cache-Control is set manually.
This issue has severity "low" according to the Django security policy.
Thanks to Ahmed Badawe for the report.
Vary: Authorization in UpdateCacheMiddlewaredjango.middleware.cache.UpdateCacheMiddleware and django.views.decorators.cache.cache_page decorator allowed responses to requests bearing an Authorization header (and without Cache-Control: public) to be cached. To conform with the existing mechanism for constructing cache keys, responses to these requests will now vary on Authorization.
This issue has severity "low" according to the Django security policy.
Thanks to Shai Berger for the report.
Vary headerdjango.middleware.cache.UpdateCacheMiddleware incorrectly cached responses whose Vary header values contained leading or trailing whitespace. Because has_vary_header() failed to strip that whitespace, a response with a Vary: * header (note the trailing space) was not recognized as containing the wildcard, causing it to be stored and potentially served from the cache when it should not have been.
This issue has severity "low" according to the Django security policy.
Thanks to Navid Rezazadeh for the report.
Patches to resolve the issue have been applied to Django's main, 6.1 (currently at alpha status), 6.0, and 5.2 branches. The patches may be obtained from the following changesets.
django.http.HttpRequest.get_signed_cookieSTARTTLS in the SMTP backendCache-Control directives in UpdateCacheMiddlewareVary: Authorization in UpdateCacheMiddlewareVary headerThe PGP key ID used for this release is Natalia Bidart: 2EE82A8D9470983E
As always, we ask that potential security issues be reported via private email
to security@djangoproject.com, and not via Django's Trac instance, nor via
the Django Forum. Please see
our security policies for further
information.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。