#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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to