一旦请求已发送到
http://www.mydomain.com/cart/
,如果请求中包含敏感数据,则为时已晚。强制使其失败!至少,它会提示您的链接出现问题。有关详细信息,请参见以前的答案:
[ ... ]当请求到达服务器时,为时已晚。如果存在MITM,则他在您收到请求之前已经执行了攻击(或其一部分)。
那么你最好能做的就是不返回任何有用的内容。在这种情况下,重定向(使用301或302和Location头)可能是适当的。但是,如果用户(甚至开发人员)忽略警告,则可能会隐藏问题(在这种情况下,���览器将透明地跟随重定向并重试请求)。
因此,我建议只需返回404状态:
http://yoursite/
和https://yoursite/
实际上是两个不同的站点。没有理由期望从一个URI空间映射到另一个URI空间的所有资源之间的1:1映射(就像您可以为ftp://yoursite/
拥有完全不同的层次结构一样)。
- 更重要的是,这是应该在上游处理的问题:使用
http://
导致用户访问此资源的链接应被视为已损坏。不要自动让它正常工作。对于不存在的资源返回404状态没问题。此外,在出现错误时返回错误消息是好的:它将迫使您(或者至少提醒您)作为开发人员需要解决导致此问题的页面/表单/链接。
编辑:(示例)
假设您有http://example.com/
,这是您网站的非安全部分,允许用户浏览商品。此时他们还没有登录,所以可以通过普通HTTP进行操作。
现在是购物/付款时间。您需要使用HTTPS。将用户发送到
https://example.com/cart/
。如果将用户发送到购物部分的链接之一使用普通HTTP(即
http://example.com/cart/
),那么这是一个开发错误。它根本不应该存在。当您认为将要被发送到
https://example.com/cart/
时,使过程中断允许开发人员看到它(一旦修复,用户就不应该有问题)。
如果只是关于指向您网站的HTTPS部分(通常是通过某个链接进行的HTTP GET),那么风险并不是那么大。
自动重定向变得更加危险的地方是它们隐藏了更大的问题。
例如,您正在
https://example.com/cart/creditcarddetails
上,并且已填写了一些应该仅保留在SSL上的信息。但是,开发人员犯了一个错误,并在表单中使用了纯粹的
http://
链接。此外,开发人员(终究是用户/人类)在Firefox中单击“不再显示此消息”时,它会说“警告:您正在从安全页面转到非安全页面”。 (顺便说一句,不幸的是,Firefox是事后警告:它已经发出了不安全的请求,同时向用户显示该消息)。现在,具有敏感数据的GET / POST请求首先发送到那个不正确的纯文本
http://
链接,并且自动重写告诉浏览器再次尝试通过
https://
发送请求。看起来很好,因为就用户而言,这一切都在瞬间发生。但实际上并非如此:敏感数据是明文发送的。
使应该仅使用HTTPS的纯HTTP部分不起任何作用实际上有助于更清楚地看到问题所在。由于如果链接正确实施,则用户永远不应该结束在那里,因此对他们来说这不是真正的问题。
/cart/
。这将迫使您确保重定向到/cart/
的所有内容都使用正确的https://
地址。重写只会隐藏开发过程中的潜在错误。不要让这些错误留在开发或生产环境中。 - BrunoRewriteRule ^cart/(.*)$ http://www.mydomain.com/
(重定向到您网站的根目录)应该足以中断该过程,同时对于那些手动调整地址栏的用户来说,这比404更好。如果您真的想重定向到HTTPS URL,请确保它始终指向无法执行任何有用处理的页面(即没有$1
)。 - Bruno