为 Heroku 应用程序安全地重定向 http 到 https

Posted 2023-02-24

【中文标题】为 Heroku 应用程序安全地重定向 http 到 https

【英文标题】：redirect http to https safely for Heroku app

【发布时间】：2018-09-20 01:50:12

【问题描述】：

我正在尝试将我的 Django + Heroku 应用程序从 http 重定向到 https，但我很惊讶我没有找到任何安全和直接的方法。

According to Heroku:

问题

您已经配置了一个 SSL 端点，现在您想要您的应用程序 对所有请求使用 https。

分辨率

重定向需要在应用程序级别执行，因为 Heroku 路由器不提供此功能。你应该编码 将逻辑重定向到您的应用程序中。

在底层，Heroku 路由器（重写）写入 X-Forwarded-Proto 和 X-Forwarded-Port 请求标头。该应用程序检查 X-Forwarded-Proto 并在不是 https 而是 http 时以重定向响应进行响应。

...

Django

将SECURE_SSL_REDIRECT 设置为True。

所以它必须在 Django 中完成。 This is the most complete answer我找到了，和this one也差不多。

Django 1.8 将核心支持非 HTTPS 重定向（集成 从 django-secure):

SECURE_SSL_REDIRECT = True
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

为了处理SECURE_SSL_REDIRECT，您必须使用 SecurityMiddleware:

MIDDLEWARE = [
    ...
    'django.middleware.security.SecurityMiddleware',
]

请注意，两者都使用

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

似乎没有这个设置，它在 Heroku 上不起作用。现在是有趣/可怕的部分。如docs 中所述：

SECURE_SSL_REDIRECT

...

如果将此设置为 True 会导致无限重定向，这可能意味着 您的网站在代理后面运行，无法分辨哪些请求是 安全，哪些不安全。您的代理可能会设置一个标头来指示 安全请求；您可以通过找出问题来纠正问题 标头是并配置 SECURE_PROXY_SSL_HEADER 设置 相应地。

然后，检查SECURE_PROXY_SSL_HEADER：

警告

如果您设置此选项，您可能会在您的网站中打开安全漏洞 不知道你在做什么。如果你没有设置它，当你 应该。认真的。

这让我想找到一个更安全的解决方案...在this other question 中它说应该没问题，但我认为它没有足够的说服力来忽略这样的警告。 p>

难道 Django 真的没有任何其他安全可以实施的解决方案吗？

我使用的是 1.11 版

---

更新：

我找到了django-sslify package，但它也需要设置SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')，所以我想它在潜在的安全漏洞方面没有什么区别。如果这个假设是错误的，请纠正我。

【问题讨论】：

一个similar question 上周居然发帖了，但是没有答案...

只是想说我在 Python 3.6.6/Django 2.1/Heroku/Gunicorn mix 上的包取得了成功。

你能写一个答案来扩展你是如何做到的吗？它可能对许多人有帮助:)

感谢@J0ANMM 联系我。事实证明仍然存在一个可能的问题。我 pip 安装了 Randall 的工作，根据文档进行了配置（包括 Heroku 的 SECURE_PROXY_SSL_HEADER）和 TBH，它解决的唯一问题是重定向问题，并且 https 没有 www 和没有 www 的错误。 http 到 https 的重定向不起作用。由于我无法确认我的应用程序是阻止程序还是代码需要更新，所以我进入了我的 DNS (CloudFlare) 并使用规则转发到 https。在停机期间，我计划在 Heroku 上启动一个测试项目以确认包操作，直到那时我正在运行。

我在这里找到了这个答案，为我工作！ ***.com/a/49112662/10407102

【参考方案1】：

我认为如果你盲目使用HTTP_X_FORWARDED_PROTO 是很危险的，因为它会让 Django 认为你正在接收 HTTPS 请求（即使 HTTP_X_FORWARDED_PROTO 实际上是被欺骗的）。

但是，如果您支持正常运行的负载平衡/代理（如 AWS），那么您可以确信 HTTP_X_FORWARDED_PROTO 设置正确。在这种情况下，HTTP_X_FORWARDED_PROTO 用于告诉 Django 它很好，不要担心（因为您相信代理不允许通过欺骗性标头），并停止尝试不断地重定向到 SSL。

最后，即使你不使用SECURE_SSL_REDIRECT = True，HTTP_X_FORWARDED_PROTO 在代理/负载平衡器后面也是必要的（例如，如果重定向发生在正确配置的 Web 服务器中，然后再进入 Django )，因为它还会影响请求上的 is_secure() 函数，如果您的代理正在吞下原始请求，这将始终是错误的（例如，从客户端和您的代理/负载均衡器之间的 HTTPS 到您的代理之间的 HTTP 是很常见的/负载平衡器和网络服务器）。

来源：Django docs: SECURE_PROXY_SSL_HEADER