#23004: Cleanse entries from request.META in debug views
---------------------------------+-----------------------------------------
Reporter: Daniel Hahler | Owner: Daniel Maxson
Type: New feature | Status: assigned
Component: Error reporting | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+-----------------------------------------
Comment (by Markus Holtermann):
Replying to [comment:20 Ryan Castner]:
> > I'm not entirely sure we need that big of a change for this ticket,
especially considering that this is a DEBUG=True
>
> That is sort of frustrating because this was my original PR
>
> https://github.com/django/django/pull/7996/files
Yikes, I did not see your PR. I'm sorry! It does look indeed a lot like
mine. I'd be ok with re-opening your PR instead.
Replying to [comment:21 Daniel Maxson]:
> My take is that we should assume that this page will end up on
production at some point. Or perhaps a developer is working on an internal
Django project and thinks it's safe to keep DEBUG=TRUE there, but someone
else on the inside maliciously leverages this. Or someone's reusing
credentials between staging and production.
>
> I would prefer not to hear that Django was how someone pivoted from HTTP
access to a debug build to acquiring secrets. Even if some of the fault
would be on bad developer practices, some of the fault would also be on
Django for leaking secrets when it didn't need to (and if it does need to
in specific situations, that's configurable for people who know what
they're doing).
>
> I think there's a strong security argument that we should assume this
data will leak, and so should be cleansed before it does.
The difference between your and Ryan/mine PRs is that yours adds the
additional functionality to specify which variables to treat as sensitive.
Considering that the entire cleaning is a best-effort approach, I don't
think that warrants the additional complexity. Especially as variables
like `HTTP_PROXY` etc may still contain secrets (and I don't think we want
to hide everything that contains `HTTP`). The ''only'' safe approach is
not showing variables in the first place.
--
Ticket URL: <https://code.djangoproject.com/ticket/23004#comment:22>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.d87f1b646bb70710e5f34c632c3d4829%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
