我在一个项目中使用 Django remote user authentication。我实际使用的只是django.contrib.auth.RemoteUserBackend 没有中间件，并在与后端检查用户合法后手动调用authenticate。
读取中间件的源代码，似乎它只是从请求中的标头中获取用户名，然后针对传递该用户名的后端对用户进行身份验证。反过来，远程用户后端只是用传递的任何用户名愉快地登录用户。然后，用户可以访问需要有效登录的每个区域。
这不只是一个巨大的安全漏洞吗？这意味着如何使用？
就我而言，我应该是安全的，因为对authenticate 的唯一调用是在成功的远程身份验证之后进行的，但我想知道引入中间件的原因。
【问题讨论】：
标签： python django security django-authentication
让我转过头来：如果您认为这是一个安全漏洞，请尝试编写一个利用程序，在对您的应用程序的请求中设置REMOTE_USER 标头，看看会发生什么。
REMOTE_USER 可以追溯到 Web 的早期，当时 CGI 页面作为您访问网页的用户在本地执行。 REMOTE_USER 实际上是一个 unix 环境变量的名称，表示活动用户。随着 Web 服务器的安全模型发生变化，为了兼容性而保留了该方案。现在甚至 IIS 也支持它透明地处理 Active Directory 登录。
所有用户传递的标头都以HTTP_ 开头。否则，您将无法信任任何标头信息，例如 SERVER_NAME，这将是一团糟。
【讨论】：
Django '愉快地登录用户'，因为您的网络服务器已检查访问者是否具有该用户名的有效凭据，并相应地设置标题。
如果您相信您的网络服务器（例如 Apache）能够正确设置 REMOTE_USER（或其他）标头，那么这不是安全漏洞。
【讨论】：
REMOTE_USER。据我了解，用户无法伪造它，因为 HTTP 标头将映射到 Django 的 request.Meta 字典中的 HTTP_REMOTE_USER 。如果您将中间件子类化并设置自定义header，那么是的，用户可以发送该header。正如我之前所说，如果您依赖网络服务器进行身份验证，那么正确配置网络服务器非常重要。
您可以查看文档here。用户无法发送带有REMOTE_USER 客户标头的请求。
警告
如果使用带有自定义 HTTP 标头的 RemoteUserMiddleware 子类，请务必小心。您必须确保您的前端 Web 服务器始终根据适当的身份验证检查设置或删除该标头，绝不允许最终用户提交虚假（或“欺骗”）标头值。由于 HTTP 标头 X-Auth-User 和 X-Auth_User（例如）都规范化为 request.META 中的 HTTP_X_AUTH_USER 键，因此您还必须检查您的 Web 服务器是否允许使用下划线代替破折号的欺骗标头。
此警告不适用于具有 header = 'REMOTE_USER' 的默认配置中的 RemoteUserMiddleware，因为在 request.META 中不以 HTTP_ 开头的键只能由您的 WSGI 服务器设置，而不是直接从 HTTP请求标头。
【讨论】：