2

我有一个 Django 服务器在 nginx 代理后面运行。我目前正在尝试通过读取来确定远程地址request.META['REMOTE_ADDR']。更准确地说:一个限制尝试暴力破解我的用户密码的应用程序(Django-brutebuster)正在这样做。

由于 Django 在 nginx 后面,REMOTE_ADDR因此是 Nginx 的地址(127.0.0.1),所以这并不是很有帮助。它还通过故意猜错密码打开了我的 DOS 应用程序,因为从蛮力破坏者的角度来看,每个人都在同一个 IP 上。

我在这个论坛上发现了类似的问题:

我想拼图的部分可以在上面找到。但是,我也认为他们为新的攻击向量打开了应用程序。具体来说,如果 Django 出于某种原因没有在 nginx 后面运行,那么自动检查 X-something 标头会从客户端打开欺骗这些标头。

令我有些惊讶的是,在上述任何问题和答案中似乎都没有提到“正确且唯一的方法”(TM)。Django 没有针对此问题的规范解决方案吗?除此之外,我们能否提出一个至少不会造成安全问题的解决方案?

4

1 回答 1

1

“The Right & Only Way To Do This” (TM) 的问题在于它需要为应用程序和部署配置提供说明。

Django 曾经有一个SetRemoteAddrFromForwardedFor中间件,但由于“这种机制不能足够可靠地用于通用用途”而被删除(您可以查看django 1.1 的发行说明

您正确地描述了问题 - 您通常不能信任Django 应用程序收到的所有标头。此类标头的情况太多特定于部署,这就是它缺乏通用解决方案的原因。

要保护此类标头,您需要在 nginx/haproxy/whatever 上强制设置此标头。

于 2013-04-04T14:55:58.690 回答