sensitive_post_parameters/sensitive_variables leaking sensitive values into the http 500 exception email

[Peter Zsoldos]

tl;dr

despite using sensitive_xxx decorator, sensitive data can end up in the 500 error emails Django sends, as these decorators only protect the data inside the very function they are decorated

repro

Is attached for all current supported Django versions (1.8, 1.10, 1.11), simply unpack and run tox

The test can seem complicated due to the limitations of the test client in testing 500 responses - see #18707

why I think it is an issue

While I'm aware of the [disclaimers in the documentation about filtering sensitive data (​https://docs.djangoproject.com/en/1.8/howto/error-reporting/#custom-error-reports), because of the impact of it - even on users who don't explicitly use any of the sensitive_x decorators themselves, I think it is a leak that should be stopped.

• typical sensitive data is passwords. We have discovered this issue due to a bug in our custom authentication backend. These passwords could also be used beyond just the single Django system - whether because of single sign on solutions like LDAP/active-directory, or simply because users might reuse their passwords across sites
• exception emails might be sent through third party providers, which may keep track of the sent message body. Internal IT departments might also be considered such 3rd parties too.
• support people (admins receiving 500 emails) see supposedly private data

potential solution ideas (which might be wrong of course :))

writing a custom exception filter

• simply don't report any variables once encountered - ​https://gist.github.com/zsoldosp/5710abaa9dedc03417d60bcc714c95d4
• keep track of protected variable names and replace those in frames further down the stack (i.e.: if parameter 'password', is sensitive, cleanse variables names 'password' too in all methods)

wrapping sensitive variables into a special object

Instead of just using the sensitive data in reporting, wrap these variables in an object that has 'contains_sensitive_data' attribute, i.e.: if it is stored into another variable, as it is a 'pointer' to the original, it will have that attribute, and thus can be filtered out in the exception report.

This isn't perfect either, e.g.: password = password.strip(), though by overriding a lot of methods or using __getattr__ magic, it could work. Might only be 'reasonable' to do so for request parameters, as there at least we know the limited set of variable types we receive

  @sensitive_request_params
  def view(request):
      ....

  # inside sensitive_request_params
  for sensitive_variable_name in sensitive_variable_names:
      if sensitive_variable_name in request.POST:
         request.POST[sensitive_variable_name] = SensitiveVariable(request.POST[sensitive_variable_name])
      ....

[Peter Zsoldos]

a minimal tox.ini/django project to repro the case