Django错误报告电子邮件：env vars泄漏信息
Django的内置功能可以在发生错误时向管理员发送电子邮件（请参阅https://docs.djangoproject.com/en/dev/howto/error-reporting/），非常方便。
但是，这些追溯电子邮件包含完整的环境变量转储。
正如django文档和其他地方（例如https://docs.djangoproject.com/en/dev/howto/deployment/checklist/）所建议的那样，我已经将一些秘密/密钥/密码移入环境变量中，作为一种简单的方法让它们远离代码库并在部署中改变它们。 不幸的是，这意味着当发生崩溃报告时，这些秘密会被清晰地发送到一组电子邮件帐户。 不是一个好习惯。
django的ExceptionReporter具有基本的过滤功能，可以取出“危险或冒犯性”的设置，例如settings.py中名称中包含字符串“pass”或“key”的任何项目的值将被替换为**** s。 因此settings.py中的密钥被编辑出来。 但是此过滤器不适用于环境变量，这些变量出现在这些错误报告的Traceback-> Local vars-> request和Request Information-> Meta部分中。
显然，还有其他方法可以管理机密，但unix环境对于小型站点而言是一种非常常见的解决方案，因为创建更复杂的配置系统是不合理的。
这似乎也有问题，这两种做法在基本的django文档中都推荐使用时不安全。
围绕站点调试信息发送电子邮件通常会泄漏信息的一些风险，但这似乎是一个重要的省略，可以通过扩展过滤来解决，也许可以通过某种设置进行控制。
有没有人已经为他们的部署修补了这个（可能扩展了django / views / debug.py中的过滤），并且/或者向django团队提交了补丁？ 或者我错过了其他一些明显的方法来解决这个问题？
好的，在我之前的检查中错过了这个，但显然django团队已经记录了大约这个bug并且在6年前将其关闭了：
https://code.djangoproject.com/ticket/7472
我会和他们一起讨论，因为我相信django在这段时间已经取得了实质性的安全进展，现在可能想要并且有一些简单的方法来解决这个问题。 :)
同时，如果您使用此电子邮件管理员功能，请注意风险。 如果你发送这些邮件，那么我会强烈建议你将所有的秘密/密码/密钥/证书/ etc放在Python配置文件中，并确保你正在清理传递给你的django web服务的（unix）环境。
我遇到了同样的问题，并通过创建自定义中间件来解决它，如Django文档中所述。 这种方法假定您知道要隐藏错误页面/电子邮件的env变量的名称，并且实际上并不需要每个请求中都存在这些变量。 然后，您可以在生成错误响应之前将它们从request.META字典中过滤出来：
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
我希望这有帮助！ 我希望Django应用相同的安全混淆规则来设置变量，因为它适用于设置，所以这甚至不是问题。
这类问题涉及处理潜在敏感信息的所有应用程序。 如果错误报告系统不构成隐私增强机制（大多数情况下），这显然是Django的情况，报告此类应用程序的错误可能会泄漏敏感信息。
错误报告中的隐私保护可以使用专用解决方案来实现，例如：
http://www.gsd.inesc-id.pt/~romanop/files/papers/ESOP14.pdf
http://research.microsoft.com/en-us/projects/betterbug/castro08better.pdf
这些系统可以与错误报告系统集成在一起，以允许在请求用户授权发送错误报告之前消除生成的错误报告的内容。
未来几个月将会有更多的新作品，其中将包括开源实现。 我将在他们出现后更新此帖子。
希望这可以帮助。
链接地址: http://www.djcxy.com/p/82939.html