Django error reporting emails: env vars leak info
Django's builtin capability of emailing admins upon errors (see https://docs.djangoproject.com/en/dev/howto/error-reporting/) is quite handy.
However, these traceback emails include a full dump of environment variables.
And as advised in the django docs & elsewhere (eg https://docs.djangoproject.com/en/dev/howto/deployment/checklist/) I've moved some secrets/keys/passwords into environment variables as a simple way to keep them away from the codebase & vary them across deployments. Unfortunately this means that when there's a crash report these secrets get sent in the clear to a set of email accounts. Not a good practice.
The django ExceptionReporter has basic filtering to pull out "dangerous or offensive" settings, so eg the value of any item in settings.py whose name contains the strings "pass" or "key" will be replaced with ****s. Thus a secret key in settings.py gets edited out. But this filter is not applied to environment variables, which appear in both the Traceback->Local vars->request and Request Information->Meta sections of these error reports.
Obviously there are other ways to manage secrets but the unix environment is a pretty common solution for small sites where creating a more complex configuration system isn't warranted.
It also seems problematic that these two practices, both recommended in the basic django docs, are unsafe when applied together.
Emailing around site debug information always carries some risk of leaking information, but this seems like a significant omission that could be addressed by expanded filtering, perhaps controlled by some setting.
Has anyone already patched this (presumably expanding the filtering in django/views/debug.py) for their deployment and/or submitted a patch to the django team? Or am I missing some other obvious way to address this?
OK, missed this in my previous checking, but apparently the django team had approximately this bug logged & closed it as will-not-fix 6 years ago:
https://code.djangoproject.com/ticket/7472
I will take it up with them, since I believe that django has made substantial security progress in the intervening time and now may want to, and have some simple ways to, address this. :)
In the meantime, if you use this email-the-admins function please be cognizant of the risk. If you send these emails then I would strongly urge you to leave or place all secrets/passwords/keys/certs/etc in python config files, and to ensure you are scrubbing the (unix) environment that is passed to your django web service.
I ran into the same issue, and addressed it by creating custom Middleware, as described in the Django docs. This approach assumes that you know the names of the env variables that you want to hide from error pages / emails, and that you don't actually need these variables present in every request. You can then filter them out from the request.META dictionary before the error response gets generated:
class RequestSafetyMiddleware(object):
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
request.META.pop('TOP_SECRET', None)
response = self.get_response(request)
return response
I hope this helps! I wish Django applied the same safety obfuscation rules to env variables as it applies to settings, so this would not even be an issue.
This type of problem regards all applications that deal with potentially sensitive information. Reporting an error of such an application, is likely to leak sensitive information, if the error reporting system composes no privacy-enhancing mechanism (most cases), which apparently is the case of Django.
Privacy protection in error reporting can be achieved using dedicated solutions, for example:
http://www.gsd.inesc-id.pt/~romanop/files/papers/ESOP14.pdf
http://research.microsoft.com/en-us/projects/betterbug/castro08better.pdf
These systems can be integrated with error reporting systems to allow sanitizing the content of the error reports generated before asking the user for authorization to transmit it.
More recent works will be available in the next few months, which will include open-source implementations. I'll update this post once they appear.
Hope this helps.
链接地址: http://www.djcxy.com/p/82940.html