#36436: Sensitive signer.key exposed via Django messages framework in templates
-------------------------------------+-------------------------------------
     Reporter:  Sarah Boyce          |                     Type:
                                     |  Cleanup/optimization
       Status:  new                  |                Component:
                                     |  contrib.messages
      Version:  5.1                  |                 Severity:  Normal
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
 The following was reported by Fredrick Peters to the Django security team.

 We’ve reviewed the issue and concluded that it can be publicly tracked as
 a hardening measure, as it assumes the attacker already has the ability to
 write Django templates. There is already a documented warning against
 untrusted template authors in the Django template documentation:
 https://docs.djangoproject.com/en/5.2/topics/templates/#module-
 django.template

 > The template system isn’t safe against untrusted template authors. For
 example, a site shouldn’t allow its users to provide their own templates,
 since template authors can do things like perform XSS attacks and access
 properties of template variables that may contain sensitive information.

 The specific issue is that when `django.contrib.messages` is in
 `INSTALLED_APPS` and the default message storage is used
 (`CookieStorage`), a template author can access:

 {{{
 {{ messages.storages.0.signer.key }}
 }}}

 This exposes the signer key used internally to sign messages, which is
 ultimately derived from Django’s `SECRET_KEY`. This is possible because
 `CookieStorage` assigns the signer as a public attribute:

 {{{#!python
 def __init__(self, *args, **kwargs):
     super().__init__(*args, **kwargs)
     self.signer = signing.get_cookie_signer(salt=self.key_salt)
 }}}

 It might still be beneficial to change `self.signer` to a private
 attribute (e.g., `self._signer`) or otherwise shield direct access to
 sensitive internals via the template context.

 This isn’t a security vulnerability but qualifies as a useful hardening
 change to prevent accidental exposure by users who may not fully
 understand the risks of template authoring.
-- 
Ticket URL: <https://code.djangoproject.com/ticket/36436>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/0107019739c4a8c8-4b697dfa-b1df-4f7b-a3cf-cef1a5250248-000000%40eu-central-1.amazonses.com.

Reply via email to