.htaccess - 为特定 URL 强制使用 HTTPS

Question

这应该很快...这是我当前的 .htaccess 文件:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

我需要做的是确保如果到达 http://www.mydomain.com/cart/，它需要强制 HTTPS ... 所以 /cart/ 和 /cart/

中的任何内容

Answer 1

一旦请求被发送到http://www.mydomain.com/cart/，如果请求中有任何敏感数据，那就太晚了。强行破解!至少，它会提示您链接有问题。先前答案中的更多详细信息:

• > https://stackoverflow.com/a/8765067/372643
• > https://stackoverflow.com/a/8964190/372643

[ ... ] by the time the request reaches the server, it's too late. If there is a MITM, he has done his attack (or part of it) before you got the request.

The best you can do by then is to reply without any useful content. In this case, a redirection (using 301 or 302 and the Location header) could be appropriate. However, it may hide problems if the user (or even you as a developer) ignores the warnings (in this case, the browser will follow the redirection and retry the request almost transparently).

Therefore, I would simply suggest returning a 404 status:

• http://yoursite/ and https://yoursite/ are effectively two distinct sites. There is no reason to expect a 1:1 mapping of all resources from the URI spaces from one to the other (just in the same way as you could have a completely different hierarchy for ftp://yoursite/).
• More importantly, this is a problem that should be treated upstream: the link that led your user to this resource using http:// should be considered as broken. Don't make it work automatically. Having a 404 status for a resource that shouldn't be there is fine. In addition, returning an error message when there is an error is good: it will force you (or at least remind you) as a developer that you need to fix the page/form/link that led to this problem.

---

编辑:(示例)

假设您有 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/creditcardsetails 上填写了一些本应保留在 SSL 上的信息。但是，开发人员犯了一个错误，在表单中使用了普通的 http:// 链接。此外，开发人员(毕竟是用户/人类)在 Firefox 显示“警告:您将从安全页面转到非安全页面”时单击“不要再向我显示此消息”(顺便说一句，不幸的是，Firefox 会发出事后警告:当它向用户显示该消息时，它已经发出了不安全的请求)。现在，带有敏感数据的 GET/POST 请求首先发送到那个不正确的普通 http:// 链接，自动重写告诉浏览器通过 https://< 再次尝试请求。它看起来很好，因为就用户而言，这一切都发生在几分之一秒内。然而，事实并非如此:敏感数据以明文形式发送。

让应该只通过 HTTPS 的纯 HTTP 部分不做任何有用的事情实际上可以帮助您更清楚地看到问题所在。如果正确实现链接，用户永远不会到达那里，所以这对他们来说不是真正的问题。