从非安全页面向安全 URL 提交表单
假设我在这个位置的页面上有一个表单...
http://mydomain.com/myform.htm
并且表单看起来像这样...
<form method="post" action="https://secure.otherdomain.com/handleform.php">
....
</form>
假设接收此表单提交的服务器上安装了有效的 SSL 证书，该表单提交的内容是否会被加密？
Suppose I have a form on a page at this location...
http://mydomain.com/myform.htm
And the form looks like this...
<form method="post" action="https://secure.otherdomain.com/handleform.php">
....
</form>
Assuming that there is a valid SSL cert installed on the server which receives this form submission will the contents of that form submission be encrypted?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
POST 请求将通过 HTTPS 传输（如果配置正确，则进行加密）。将通过纯 HTTP 获取的页面中的表单提交到 HTTPS 页面是不好的做法。初始页面也应通过 HTTPS 提供。原因是 MITM 攻击者可以拦截使用表单加载页面的响应，并替换链接以指向另一个目标。
请参阅此处的第一条规则（当然，不特定于登录页面）：
The POST request will be transmitted over HTTPS (so encrypted if configured properly). Submitting a form from a page obtained over plain HTTP to an HTTPS page is bad practice. The initial page should also be served over HTTPS. The reason for this is that a MITM attacker could intercept the response that loads the page with the form and replace the link to point to another target.
See the first rule here (of course, not specific to login pages):
假设服务器和客户端之间可以协商有效的 SSL/TLS 会话，那么可以。这意味着客户端必须愿意信任服务器提供的任何证书，并且两方可以协商双方都同意的密码集（使用什么算法等）。您可以设置很多配置选项来更改允许的内容，但在“正常”实现中，您不会胡乱要求特定的非正常算法、需要客户端证书身份验证等，一切都应该工作得很好，并且您将拥有一个受保护的会话...如果由于某种原因失败，您会知道您的客户端将收到有关出错原因的错误。
请注意，一般来说，虽然您可以这样做，并且传输会被加密，但通常不应该这样做。提交未加密/受保护的页面会让您容易受到几种类型的中间人攻击。您可以在此处查看有关此问题的 OWASP 文章以及为什么它不好。
Assuming a valid SSL/TLS session can be negotiated between the server and the client, then yes. This means that the client must be willing to trust whatever certificate the server presents and that the two parties can negotiate a mutually-agreeable cipher set (what algorithms to use, etc). There are plenty of configuration options you can set to alter what is allowed, but in a "normal" implementation where you don't go messing around with requiring a specific, non-normal, algorithm, requiring client-side certificate authentication, etc, everything should work just fine and you'll have a protected session...and if it fails for some reason, you'll know as your client will receive an error about what went wrong.
Note that, in general, while you can do this, and the transmission would be encrypted, you generally should not. Having an unencrypted/protected page submit to one leaves you vulnerable to a couple types of Man in the Middle attacks. You can see the OWASP article on this, and why it's bad, here.
是的。它将被安全地传输。
Yes. It will be transmitted securely.