#28215: sensitive_post_parameters/sensitive_variables leaking sensitive values
into
the http 500 exception email
---------------------------------+--------------------------------------
Reporter: Peter Zsoldos | Owner: (none)
Type: Bug | Status: new
Component: Error reporting | Version: 1.8
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
---------------------------------+--------------------------------------
Comment (by Peter Zsoldos):
Tim,
thanks for the feedback. For the time being, I copypasted the repro
unittest's main body into the ticket so it's more accessible.
As for the suggested fix, I think there are two separate issues here
1. sensitive data across django's own internal code is not marked
everywhere as sensitive. This can be fixed manually once and that would be
a great improvement.
* There is one scenario highlighted in this ticket (error during
login),
* Probably all `sensitive_post_parameter` decorated views need to be
reviewed & followed through the code paths to ensure all sensitive
variables in all methods are decorated
* For future code changes, checking for the need to update the
sensitive parameters would need to be done too.
* this only fixes things in Django's own code though, not issues in
third party code, though it could be argued that they should write secure
code & users of 3rd party code should do due diligence...
1. however, some generic code might be used from multiple contexts, even
from multiple `sensitive_post_parameter` views - e.g.:
`MyModel.objects.get`. In some contexts, `username` field might be
sensitive (e.g.: login), but in others (e.g.: admin search) it might not.
See the below simplified unittest to repro it - it is displayed for the
frame `django/db/models/query.py` in `get`.
{{{#!python
@sensitive_variables('username') # to exclude the local var in the
stacktrace here
def test_leaking_data_due_to_exception_in_generic_method(self):
class TestError(ValueError):
pass
@sensitive_post_parameters('username')
def some_view(request):
"""
based on docstring from sensitive_post_parameters itself,
storing it into a local variable.
But same issue would happen if I the User.objects.get raised
the User.DoesNotExist error - and how should the generic
QuerySet.get be annotated with regards to all sensitive
parameters?
"""
uname = request.POST['username']
User.objects.get(username=request.POST['username'])
raise TestError('some error')
username = 'some_username'
rf = RequestFactory()
request = rf.post('/submit/', {'username': username})
try:
some_view(request)
raise ValueError('expected to raise an error')
except (TestError, User.DoesNotExist) as e:
exc_type, exc_value, tb = sys.exc_info()
# based on django.utils.log.AdminEmailHandler.emit
reporter = ExceptionReporter(
request=request, is_email=True,
exc_type=exc_type, exc_value=exc_value, tb=tb)
self.assertTrue(reporter.filter.is_active(request))
error_mail_html = reporter.get_traceback_html()
self.assertNotIn(
member=username, container=error_mail_html)
}}}
Maybe the ticket should be split in two? 'coz doing 1. would already
improve the situation quite a bit, but to support 2. might be a bigger
effort. But I like the test repro for 2 better than the original report's
- not replacing the ticket description with it until I know whether the
ticket will be split
--
Ticket URL: <https://code.djangoproject.com/ticket/28215#comment:5>
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/066.12428c5803a61f6fa8f0bdbaebe6caca%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
