从 HTTP 表单提交到 HTTPS 是否安全？

将表单从 http 页面发布到 https 页面，可以在以最简单的术语传输表单中的数据时对其进行加密。如果有中间人攻击，浏览器会提醒你。

但是，如果原始的 http 表单受制于 man-in-the-mid，并且 https 回发地址被攻击者修改，那么您将得不到任何警告。数据实际上仍然是加密的，但是中间人攻击者将能够解密(因为他首先向您发送了密钥)并读取数据。

此外，如果表单是通过其他方式(脚本连接)发送回来的东西，有可能在表单发布之前通过电子邮件发送未加密的数据(尽管任何好的网站都不会对任何类型的敏感数据这样做)。

没有在整个事务中使用 HTTPS 有什么原因吗？如果你找不到一个很好的，使用它！

• 可以说比交换协议更简单。

• MITM 的风险是真实存在的。

• 在您的链接之后，用户“ Helios”提出了一个极好的观点，即使用100% HTTPS 对用户来说更不容易混淆。

这篇文章是关键。是的，如果用户的数据被发送给您，它将安全地到达某个地方。但是没有理由相信你的网站会出现在某个地方。此时，攻击者不会仅仅监听向各个方向移动的数据。他将是用户会话的另一端。您的站点只会认为用户从来没有麻烦提交表单。

不，从 HTTP 到 HTTPS 是不安全的。要建立和使用安全信道，请求的起始点和结果点必须是 HTTPS。

这种事情在网络上随处可见，特别是在那些可以选择登录的网站上。然而，由于一些非常微妙的原因，它本质上是不安全的，并且给用户一种错误的安全感。我想最近 Codinghorror.com上有一篇关于这个的文章。

危险在于，当您使用 post 目标“ https://xxx”发送页面时，该引用所在的页面是不安全的，因此攻击者可以在传输过程中对其进行修改，以指向攻击者希望指向的任何 URL。因此，如果我访问您的网站，我必须查看来源，以验证我的证书是被张贴到一个安全的地址，并验证有相关性 只有的特定提交。如果我明天返回，我必须再次查看源代码，因为那个特定的页面交付可能已经被攻击并且 post 目标已经被破坏了——如果我不每次都验证，当我知道 post 目标已经被破坏的时候，已经太晚了——我已经把我的凭证发送到攻击者的 URL。

您应该 只有提供一个到登录页面的链接; 只要您登录，登录页面及其后的所有内容都应该是 HTTPS。实际上，没有理由不这样做; SSL 的负担在于最初的协商; 后续的连接将使用 SSL 会话缓存，而用于链接数据的对称加密实际上开销非常低。

Jay 和 Kiwi 关于 MITM 袭击的说法是对的。然而，需要注意的是，攻击者不必破坏表单并给出一些错误消息; 相反，攻击者可以插入 JavaScript 将表单数据发送两次，一次发送给他，一次发送给您。

但是，说实话，您必须要问，攻击者拦截您的登录页面并在运行中修改它的可能性有多大？比较下面的风险: (a)在 SSL 会话中进行 MITM 攻击，并希望用户按“ OK”继续; (b)在最初重定向到 SSL 时进行 MITM 攻击(例如，从 http://example.com到 https://example.com) ，然后重定向到攻击者控制的 https://doma1n.com; (c)在站点的某个地方出现 XSS、 XSRF 或 SQL 注入缺陷。

是的，我建议在 SSL 下运行登录表单，没有任何理由不这样做。但如果不是这样，我也不会太担心，可能还有更低的悬挂水果。

更新

以上答案来自2008年。自那以后，许多额外的威胁变得明显起来。例如，从随机的不可信网络(如 WiFi 热点)访问站点(附近的 任何人可能会实施这种攻击)。现在我会说是的，你肯定应该加密您的登录页面，并进一步您的整个网站。此外，现在已经有了初始重定向问题(HTTP严格传输安全)的解决方案。开放 Web 应用程序安全项目提供了一些最佳实践指南。

对于我(作为一个终端用户)来说，HTTPS 会话的价值不仅在于数据被加密，而且在于我可以验证我输入超级机密的页面是否来自我想要的地方。

将表单放在非 HTTPS 会话中会破坏这种保证。

(我知道——这只是表示表单受到 MITM 攻击的另一种说法)。

我认为这个问题的主要考虑与用户知道的 URL 和浏览器默认替换的协议方案(http:)有关。

在这种情况下，希望确保加密通道的站点的正常行为是将 http://home-page重定向到 https://home-page。仍然存在欺骗/MitM 的机会，但如果是 DNS 中毒，风险并不高于如果开始使用 https: URL。如果一个不同的域名回来了，你需要担心。

这里应该够安全了。毕竟，如果你受制于一个目标的 MitM，你可能会开始担心键盘记录器，你的本地主机文件，以及各种各样的方式找出你的安全交易涉及你的系统已经被拥有。

IE Blog 解释: < strong > 关键错误 # 1: 非 HTTPS 登录页面(即使提交到 HTTPS 页面)

• 用户如何知道表单是通过 HTTPS 提交的？大多数浏览器没有这样的 UI 提示。
• 用户如何知道它正在访问正确的 HTTPS 页面？如果登录表单是通过 HTTP 传递的，那么不能保证它在服务器和客户端之间没有被更改。

每个建议您只提供登录页面链接的人似乎都忘记了使用 MITM 攻击可以很容易地更改链接。

上面所提到的最大的遗漏之一就是在主页上放置一个登录名是一种普遍趋势(用户体验趋势中的巨大趋势)。

这里的大问题是谷歌不喜欢有充分理由搜索安全页面，所以所有那些开发人员都想知道为什么不让它们都安全，好吧，如果你想让你的页面对谷歌不可见，那就全部安全。否则，从 http 发布到 https 的第二个最佳选择是两害相权取其轻？