[Django] #36542: Improve default error reports filtering (both HTML email reports when DEBUG=False and regular reports when DEBUG=True)

[Django]

#36542: Improve default error reports filtering (both HTML email reports when
DEBUG=False and regular reports when DEBUG=True)
-------------------------------------+-------------------------------------
Reporter: Olivier Dalang | Type:
| Uncategorized
Status: new | Component: Error
| reporting
Version: 5.2 | 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
-------------------------------------+-------------------------------------
Hey !

Recently I came accross plain text user passwords in debug reports when
there is an exception on the login view. Such exceptions can happen very
easily in many basic scenarios such as an unreachable database. The
passwords are visible in:

1/ regular debug reports when DEBUG=True

(screenshot incomming)

2/ email reports when DEBUG=False and include_html=True

(screenshot incomming)

I reported this to the security team, but quite reasonably they decided
it's not a security issue since it's very clear no one should use
DEBUG=True in PROD (and there, users would just see their own password
anyway), and that the docs already warn quite a bit against enabling
"include_html" in email reports. Yet they agreed this is still worth
improving.

For context, Django already redacts much less critical infos by default in
the report such as the csrftoken or internal settings, even if these are
harder to exploit and unlike user passwords usually already known to
admins. Having such info redacted gives some false sense of security about
these reports.

I didn't test but think there are other cases in django core such as user
creation forms (password1, password2) or password changes (old_password,
new_password1, new_password2), and of course this would also happen in
third party apps / user code.

In terms of fixing this, 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 ? I feel this would
cover most cases and be quite straightforward to implement and to
understand for users. For that matter, better to redact too many variables
than too few.

Cheers !
--
Ticket URL: <https://code.djangoproject.com/ticket/36542>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#36542: Improve default error reports filtering (both HTML email reports when
DEBUG=False and regular reports when DEBUG=True)

---------------------------------+--------------------------------------
Reporter: Olivier Dalang | Owner: (none)

Type: Uncategorized | Status: new
Component: Error reporting | Version: 5.2

Severity: Normal | Resolution:

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

---------------------------------+--------------------------------------
Changes (by Olivier Dalang):

* Attachment "image (1).png" added.

[Django]

#36542: Improve default error reports filtering (both HTML email reports when
DEBUG=False and regular reports when DEBUG=True)
---------------------------------+--------------------------------------
Reporter: Olivier Dalang | Owner: (none)
Type: Uncategorized | Status: new
Component: Error reporting | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Changes (by Olivier Dalang):

* Attachment "image.png" added.

[Django]

#36542: Improve default error reports filtering (both HTML email reports when
DEBUG=False and regular reports when DEBUG=True)
---------------------------------+--------------------------------------
Reporter: Olivier Dalang | Owner: (none)
Type: Uncategorized | Status: new
Component: Error reporting | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------

Description changed by Olivier Dalang:

Old description:

New description:

Hey !

Recently I came accross plain text user passwords in debug reports when
there is an exception on the login view. Such exceptions can happen very
easily in many basic scenarios such as an unreachable database. The
passwords are visible in:

1/ regular debug reports when DEBUG=True

https://code.djangoproject.com/attachment/ticket/36542/image.png

2/ email reports when DEBUG=False and include_html=True

https://code.djangoproject.com/attachment/ticket/36542/image%20(1).png

I reported this to the security team, but quite reasonably they decided
it's not a security issue since it's very clear no one should use
DEBUG=True in PROD (and there, users would just see their own password
anyway), and that the docs already warn quite a bit against enabling
"include_html" in email reports. Yet they agreed this is still worth
improving.

For context, Django already redacts much less critical infos by default in
the report such as the csrftoken or internal settings, even if these are
harder to exploit and unlike user passwords usually already known to
admins. Having such info redacted gives some false sense of security about
these reports.

I didn't test but think there are other cases in django core such as user
creation forms (password1, password2) or password changes (old_password,
new_password1, new_password2), and of course this would also happen in
third party apps / user code.

In terms of fixing this, 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 ? I feel this would
cover most cases and be quite straightforward to implement and to
understand for users. For that matter, better to redact too many variables
than too few.

Cheers !

--

--
Ticket URL: <https://code.djangoproject.com/ticket/36542#comment:1>