为特定 URL 强制使用 HTTPS [英] Force HTTPS for specific URL

问题描述

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

This should be a quick one... here is my current .htaccess file:

# 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/

What I need to do is make sure that if http://www.mydomain.com/cart/ is reached, it needs to force HTTPS ... so /cart/ and anything within /cart/

推荐答案

一旦请求被发送到 http://www.mydomain.com/cart/，如果有任何敏感数据在请求中，为时已晚.强行破解！至少，它会给您一个指示，表明您的链接有问题.先前答案中的更多详细信息:

Once the request has been sent to http://www.mydomain.com/cart/, if there is any sensitive data in the request, it's too late. Force it to break! At least, it will give you an indication that there's something wrong with your links. More details in previous answers:

• 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.

到那时你能做的最好的事情就是在没有任何有用内容的情况下回复.在在这种情况下，重定向(使用 301 或 302 和 Location 标头)可能是合适的.但是，如果用户(或即使您作为开发人员)也会忽略警告(在这种情况下，浏览器将跟随重定向并几乎重试请求透明).

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).

因此，我只是建议返回 404 状态:

Therefore, I would simply suggest returning a 404 status:

• http://yoursite/ 和 https://yoursite/ 实际上是两个不同的站点.没有理由期望所有的 1:1 映射来自 URI 空间的资源从一个到另一个(只是在相同的因为你可以有一个完全不同的层次结构ftp://yoursite/).
• 更重要的是，这是一个应该在上游处理的问题:使用 http:// 将您的用户引导至此资源的链接应该被认为是破碎的.不要让它自动工作.对于不应该存在的资源具有 404 状态是可以的.在另外，有错误时返回错误信息是好的:它会迫使您(或至少提醒您)作为开发人员，您需要修复导致此问题的页面/表单/链接.

• 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 登录.

Let's say you have http://example.com/, the non-secure section of your site that allows the user to browse items. They're not logged in at that stage, so it's fine to do it over plain HTTP.

现在是购物车/付款时间.你想要 HTTPS.您将用户发送到 https://example.com/cart/.如果将用户发送到购物车部分的链接之一使用纯 HTTP(即 http://example.com/cart/)，则是开发错误.它不应该在那里.当您认为自己将被发送到 https://example.com/cart/ 时，中断流程允许开发人员看到它(并且，一旦修复，用户应该永远不会遇到问题).

Now, it's cart/payment time. You want HTTPS. You send the user to https://example.com/cart/. If one of the links that sends the user to the cart part is using plain HTTP (i.e. http://example.com/cart/), it's a development mistake. It just shouldn't be there. Making the process break when you thought you were going to be sent to https://example.com/cart/ allows the developer to see it (and, once fixed, the user should never have the problem).

如果只是指向您网站的 HTTPS 部分(通常是通过某个链接的 HTTP GET)，那么风险不一定那么大.

If it's just about the point to the HTTPS section of your site (typically, an HTTP GET via a link somewhere), it's not necessarily that big a risk.

自动重定向变得更加危险的地方在于它们隐藏了更大的问题.

Where automatic redirects become even more dangerous is when they hide bigger problems.

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

For example, you're on https://example.com/cart/creditcarddetails and you've filled in some information that should really just stay over SSL. However, the developer has made a mistake and a plain http:// link is used in the form. In addition, the developer (a user/human after all) has clicked on "don't show me this message again" in Firefox when it says "Warning: you're going from a secure page to a non-secure page" (by the way, unfortunately, Firefox warns a posteriori: it has already made the insecure request by the time it shows the user that message). Now, that GET/POST request with sensitive data is sent first to that incorrect plain http:// link and the automatic rewrites tells the browser to try the request again over https://. It looks fine because, as far as the user is concerned, this all happened in a fraction of a second. However, it's not: sensitive data was sent in clear.

让纯 HTTP 部分只应通过 HTTPS 不做任何有用的事情实际上可以帮助您更清楚地看到问题所在.如果链接正确实施，用户无论如何都不应该最终到达那里，因此这对他们来说并不是真正的问题.

Making the plain HTTP section of what should only be over HTTPS not do anything useful actually helps you see what's wrong more clearly. Since the users should never end up there anyway if the links are correctly implemented, this isn't really an issue for them.

这篇关于为特定 URL 强制使用 HTTPS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！