【问题标题】:Prevent http page from redirecting to https page防止http页面重定向到https页面
【发布时间】:2018-02-03 01:15:23
【问题描述】:

我有一个网站 (userbob.com),通常以 https 的形式提供所有页面。但是,我试图让一个子目录 (userbob.com/tools/) 始终以 http 形式提供内容。目前,Chrome 的 HSTS 功能(我不明白它是如何工作的)似乎正在强制我的网站页面通过 https 加载。我可以转到 chrome://net-internals/#hsts 并从 Chrome 的 HSTS 集中删除我的域,下一个查询将按我的意愿工作,而无需重定向到 https 版本。但是,如果我再次尝试加载页面,它最终会再次重定向。我可以让它工作的唯一方法是,如果我去 chrome://net-internals/#hsts 并在每次请求后从 Chrome 的 HSTS 集中删除我的域。如何让浏览器知道我希望来自 userbob.com/tools/ 的所有页面都加载为 http?我的网站使用 apache/tomcat 网络服务器。

(仅供参考,我希望工具目录中的页面通过 http 而不是 https 提供页面的原因是因为其中一些用于 iframe http 页面。如果我尝试从 https 页面 iframe 中的 http 页面我最终会出现混合内容错误。)

【问题讨论】:

    标签: apache ssl browser https hsts


    【解决方案1】:

    HTTP 严格传输安全(或 HSTS)是您的网站可以发送到浏览器的设置,上面写着“我只想在我的网站上使用 HTTPS - 如果有人尝试访问 HTTP 链接,请先自动将其升级到 HTTPS发送请求”。它基本上不允许您发送任何 HTTP 流量,无论是有意还是无意。

    这是一项安全功能。 HTTP 流量可以被拦截、读取、更改并重定向到其他域。仅 HTTPS 的网站应该将 HTTP 流量重定向到 HTTPS,但如果任何请求最初仍通过 HTTP 发送,则会出现各种安全问题/攻击,因此 HSTS 可以防止这种情况。

    HSTS 的工作方式是您的网站在您的 HTTPS 请求中发送一个 HTTP 标头 Strict-Transport-Security,其值为例如 max-age=31536000; includeSubDomains。在本例中,浏览器缓存并激活 HSTS 31536000 秒(1 年)。您可以在浏览器 Web 开发人员工具中或使用类似 https://securityheaders.io 的网站查看此 HTTP 标头。通过使用chrome://net-internals/#hsts 站点,您可以清除该缓存并再次允许HTTP 流量。但是,一旦您通过 HTTPS 访问该站点,它将再次发送标头,并且浏览器将恢复为仅 HTTPS。

    因此,要永久删除此设置,您需要停止发送 Strict-Transport-Security 标头。在您的 Apache/Tomcat 服务器中找到它并将其关闭。或者更好的是先将其更改为max-age=0; includeSubDomains(它告诉浏览器在0秒后清除缓存,然后将其关闭而不必访问chrome://net-internals/#hsts,只要您通过HTTPS访问该站点即可获取这个 Header,然后在以后完全删除 Header。

    关闭 HSTS 后,您可以恢复为某些页面使用 HTTPS,而另一些页面使用标准重定向的 HTTP。

    但是,如果我不警告您不要返回 HTTP,那将是我的疏忽。 HTTPS 是新标准,并且普遍推动鼓励所有站点迁移到 HTTPS 并惩罚那些不这样做的站点。阅读他的帖子了解更多信息:

    https://www.troyhunt.com/life-is-about-to-get-harder-for-websites-without-https/

    虽然您无法在 HTTPS 页面上构建 HTTP 内容是正确的,但您应该考虑是否有其他方法可以解决此问题。您站点上的单个 HTTP 页面可能会导致安全问题,例如泄漏 cookie(如果它们设置不正确)。 Plus 框架很糟糕,不应该再使用了:-)

    【讨论】:

    • 感谢您的详尽回答。我最终修改了我的工具以仅支持 iframeing https 页面。
    • How to remove Strict-Transport-Security 在答案中会很有用
    • 这完全取决于它是如何添加的。可能在 Apache 配置中。可能来自后端系统。可以预载。所以问题中没有足够的信息来回答这个问题。此外,由于有很多方法可以做到这一点,我认为这对于其他人的答案也不是那么有用。
    【解决方案2】:

    基本上任何来自 HTTPS 请求的 HTTP 301 响应表明目标重定向到 HTTP 绝不应该被任何浏览器所接受,那些这样做的服务器显然违反了基本安全性,或者受到了许多损害。 但是,对 HTTPS 请求的 301 回复仍然可以重定向到另一个 HTTPS 目标(包括在另一个域上,前提是满足其他 CORS 要求)。

    如果您浏览 HTTPS 链接(或 javascript 事件处理程序)并且浏览器开始加载响应 301 重定向到 HTTP 的 HTTPS 目标,则浏览器的行为应该类似于 500 服务器错误或连接失败(DNS 名称未解析,服务器未响应超时)。

    这样的服务器端重定向显然是无效的。网站管理员永远不应该这样做!如果他们想关闭服务并通知 HTTPS 用户该服务托管在其他地方并且不再安全,他们必须返回一个有效的 HTTPS 响应页面,根本没有重定向,这应该是一个 4xx 错误页面(很可能是 404 PAGE NOT FOUND),并且他们不应重定向到不遵守 CORS 要求或发送虚假媒体类型的另一个 HTTPS 服务(例如第三方托管的搜索引擎或停车页面)(可以接受不遵守请求的语言和显示该页面以另一种语言显示)。

    实现 HSTS 的浏览器是完全正确的,并且朝着正确的方向发展。但我真的认为 CORS 规范是一团糟,只是进行了调整,以仍然允许广告网络托管和控制自己向其他网站广播的广告。

    我强烈认为,出于正当理由仍希望展示广告(或任何用于受众测量的跟踪器)的严肃网站可以自己托管这些广告/跟踪器,在自己的域上并使用相同的协议:服务器仍然可以让自己获得他们想要通过下载/刷新这些广告并维护自己的本地缓存来广播的广告内容。如果他们希望第三方分析这些数据,他们可以通过收集他们需要和想要的数据并在自己的服务器上对其进行过滤来自行跟踪他们的受众:网站必须认真执行自己的隐私要求。

    我现在讨厌那些在访问时被数十个第三方跟踪的太多网站,包括非常侵入性的网站,如 Facebook 和大多数广告网络,以及许多质量/安全性非常差的非常薄弱的​​第三方服务,以及发送他们无法控制的非常糟糕的内容(包括虚假广告、虚假新闻、宣传非法活动、非法业务、无效年龄分级......)。

    让我们回到网络的起源:一个站点、一个域、一个第三方。这并不意味着他们不能链接到其他第三方网站,但这些必须仅通过明确的用户操作(点击或点击)来完成,并且访问者必须能够知道这将转到哪里,或者将显示哪些内容.

    这甚至可以用于在新闻文章中插入视频(例如 Youtube):新闻网站可以为自己托管一个用于框架的静态图像缓存和用于“播放”按钮的图标:当用户单击该图标时,它将启动激活第三方视频,在这种情况下,第三方将直接与该用户交互并可以收集其他数据。但未激活的内容将仅由源网站根据其发布的政策进行跟踪。

    【讨论】:

      【解决方案3】:

      您可以使用重写规则将 https 请求重定向到子目录内的 http。在tools目录下创建.htaccess文件,添加如下内容:

      RewriteEngine On
      RewriteCond %{HTTPS} on
      RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
      

      确保 apache mod_rewrite 已启用。

      【讨论】:

      • 感谢您的建议。但是,如果我这样做,Chrome 最终会显示 ERR_TOO_MANY_REDIRECTS 错误。似乎我的服务器试图以这种方式强制使用 http,Chrome 坚持认为该页面应作为 https 加载,服务器以 301 重定向响应 http 页面,然后 Chrome 请求 https 页面,此循环重复,直到 Chrome 放弃.
      猜你喜欢
      • 2021-01-10
      • 1970-01-01
      • 2016-12-12
      • 2015-06-05
      • 1970-01-01
      • 2013-10-18
      • 1970-01-01
      • 1970-01-01
      • 2015-08-11
      相关资源
      最近更新 更多