#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 kanin.kearpimy@…):

 Hi,

 Let me sum it up and please correct me if something doesn't make sense.
 So, now the problem is we doesn't have `sensitive_post_parameters` and
 `sensitive_variables` to cover sensitive  function parameters, in this
 case `password`-related for POST request. That's why in `DEBUG=True`,
 there is `password`-related field appear?

 Regarding below
    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 ?

 it may doesn't help to broadly filter `password` in POST, because deeper
 down the stack still isn't covered by `sensitive_post_parameters` OR
 `sensitive_variables` as Tim mentioned here
    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

 As Jacob shared there was a PR did such similar thing before in #35930
    Noting we have an accepted ticket for that in #35930 with respect to
 the methods for initiating a database connection.

 So, it's good idea to imitate the #35930 approach and cover up all auth
 app function with local password-y varialbes?
-- 
Ticket URL: <https://code.djangoproject.com/ticket/36542#comment:11>
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/0107019d2538df7b-9116ccf1-ef5e-4f91-81ab-adb79c25a2d9-000000%40eu-central-1.amazonses.com.

Reply via email to