#36542: AdminSite views (such as login) leak sensitive POST data
-------------------------------------+-------------------------------------
Reporter: Olivier Dalang | Owner: (James)
| Kanin Kearpimy
Type: Bug | Status: assigned
Component: contrib.admin | Version: 5.2
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 Tim McCurrach):
I’ve just taken a look at the PR, and I think it’s worth expanding on a
few things in this ticket for the sake of clarity:
- If `DEBUG` is `False`, both sensitive variables and sensitive post
parameters are always cleaned/redacted from debug-reports. This holds,
even when `include_html=True`.
- As far as I can tell, all of the built-in auth views are decorated with
the appropriate `sensitive_post_parameters` decorators.
- The admin login views use the aforementioned built-in views for most of
the heavy lifting, and so are protected to. (This is because even if the
“top-level” view isn’t decorated, `sensitive_post_parameters` gets set on
the request further down - which is all that matters).
- Most of the
associated authentication functions are decorated with the appropriate
sensitive_variables decorators.
The above is to say, that all-in-all, even with `include_html=True`
everything is actually already pretty well locked down. The reason the
password appears in the screenshot above is that some of the functions
deeper down the stack (at the auth-backend / model level) aren’t decorated
with the `sensitive_variables` decorator.
I wonder if the docs are potentially misleading on this. They say:
>The include_html argument of AdminEmailHandler is used to control whether
the traceback email includes an HTML attachment containing the full
content of the debug web page that would have been produced if DEBUG were
True.
This is maybe a little bit ambiguous. My reading of the above would be
that sensitive variables would remain unfiltered - but that isn't true.
----
Regarding the original suggestion:
> why don't we just apply the same filter used for settings
`(API|AUTH|TOKEN|KEY|SECRET|PASS|SIGNATURE|HTTP_COOKIE)` to POST
parameters as well as variables in the full trace ?
This won’t actually help the POST parameters since they are already
filtered when `DEBUG` is `False`. It would cover a few more of the
sensitive variables, but I think we could (maybe should) patch up the last
few remaining functions in the auth app, that have any local variables
that are password-y in them with the `sensitive_variables` decorator.
Doing a quick search there don’t seem to be too many. That way, we still
have all the local variable data for debugging.
--
Ticket URL: <https://code.djangoproject.com/ticket/36542#comment:8>
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/0107019d10ae1f09-89158da0-a4c4-4ee8-b2e1-8065ad6265f3-000000%40eu-central-1.amazonses.com.
