如果调用者不使用 HTTPS，如何阻止访问 PHP 文件？
我编写了几个 PHP Web 服务，通过 URL 传递参数。为了防止未经授权的访问，我传入一个唯一密钥作为参数之一。我通过 HTTPS 调用 PHP 文件，我想知道是否有办法在不使用 HTTPS 的情况下阻止脚本运行。
I have written several PHP web services where I pass in arguments via the URL. To prevent unauthorized access, I pass in a unique key as one of the arguments. I call the PHP file via HTTPS, and I am wondering if there's a way I can prevent the script from running if HTTPS is not used.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
稍微偏离主题，但如果您将 PHP 与 Apache Httpd 和
mod_ssl一起使用，则可以通过将SSLRequireSSL指令位于.htaccess或目录配置中。Slightly off topic, but if you're using PHP with Apache Httpd and
mod_ssl, you can force SSL access to files (and PHP scripts) by placing theSSLRequireSSLdirective in.htaccessor in the Directory configuration.澄清一下：您希望客户端不会通过非加密连接调用包含秘密令牌的 URL，对吗？如果是这样，那么问题主要不是出在你身上，而是出在客户端的浏览器上。如果客户端尚未使用安全连接，您可以将其重定向到安全连接，但即使您这样做，客户端在被重定向之前已经向您的服务器发出了不安全的、可拦截的请求！
Mozilla 正在努力解决这个问题。从 Firefox 4 开始，服务器可能会发送一个
Strict-Transport-Security标头，这将阻止随后的未加密访问（尽管显然在发送标头之前，未加密的访问仍然可能发生。）进一步阅读 hacks.mozilla.org
To clarify: You want that a client doesn't call a url containing a secret token over a non-encrypted connection, is that right? If so, then the problem is mainly not with you, but with the browser of the client. You may redirect the client to a secure connection if he isn't using one yet, but even if you do so the client already made an insecure, interceptable request to your server, before he get's redirected!
Mozilla is making an effort to solve this problem. As of Firefox 4 a server may send a
Strict-Transport-Securityheader which will prevent an unencrypted access subsequently (though obviously before the header was sent an unencrypted access could still happen.)Further reading at hacks.mozilla.org
如果您使用 Apache，则可以使用 mod_rewrite 将 http 请求重定向为 https 请求。
例如，这就是我们使用的：
这会将 http://domain/account 重定向到 https://域/帐户
If you are using Apache, you could use mod_rewrite to redirect http requests to be https ones.
For e.g. This is what we use:
This redirects http://domain/account to https://domain/account
您可以阻止服务器响应未加密的请求，但无法阻止客户端发送该请求，这对密码安全同样不利。到目前为止，这还不是在 URL 中放置秘密令牌的最严重问题：它保留在浏览器历史记录中，当用户离开您的网站时可以在引用站点中看到它，并且用户访问的任何网站都可以启动暴力攻击 -通过
:visitedCSS 伪类进行强制或字典攻击。总而言之，这是一个非常可怕的想法 - 您最好使用仅 SSL cookie。You can prevent the server responding to an unencrypted request, but you cannot prevent the client sending it, which is just as bad for password security. And that is not by far the worst problem with putting a secret token in the URL: it remains in the browser history, it can be seen in the referer when the user leaves your site, and any website the user visits can launch a brute-force or dictionary attack via the
:visitedCSS pseudo-class. All in all, it is a pretty horrible idea - you are better off using SSL-only cookies.