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

Posted 2023-02-25

【中文标题】从 HTTP 表单提交到 HTTPS 是不是安全？

【英文标题】：Is it secure to submit from a HTTP form to HTTPS?从 HTTP 表单提交到 HTTPS 是否安全？

【发布时间】：2010-09-21 10:00:05

【问题描述】：

是否可以通过 https 从 http 表单提交？看起来它应该是安全的，但它允许中间人攻击 (here is a good discussion)。像mint.com 这样的网站允许您从 http 页面登录，但会发布 https 帖子。在我的站点中，请求是有一个 http 登录页面，但能够安全登录。是否不值得冒可能的安全风险，我应该让所有用户转到安全页面登录（或使登录页面安全）？

【问题讨论】：

youtube.com/watch?v=nm-85-bDP6c

【参考方案1】：

Jay 和 Kiwi 对 MITM 攻击的看法是正确的。然而，重要的是要注意攻击者不必破坏表单并给出一些错误消息；攻击者可以插入 javascript 来发送表单数据两次，一次给他，一次给你。

但是，老实说，您必须问，攻击者拦截您的登录页面并在飞行中修改它的可能性有多大？它与 (a) 在 SSL 会话上进行 MITM 攻击并希望用户按“确定”继续的风险相比如何； (b) 在初始重定向到 SSL 时执行 MITM（例如，从 http://example.com 到 https://example.com）并改为重定向到 https://doma1n.com，这是在攻击者的控制之下； (c) 您的网站某处存在 XSS、XSRF 或 SQL 注入漏洞。

是的，我建议在 SSL 下运行登录表单，没有任何理由不这样做。但如果不是这样，我也不会太担心，可能还有很多更容易实现的目标。

更新

以上答案来自 2008 年。从那时起，许多其他威胁变得明显。例如，从随机的不受信任的网络（例如 WiFi 热点）访问站点（附近的任何人都可能发起该攻击）。现在我会说是的，您绝对应该加密您的登录页面，并进一步加密您的整个网站。此外，现在有初始重定向问题的解决方案（HTTP 严格传输安全）。 Open Web Application Security Project 提供了几个最佳实践指南。

【讨论】：

是的，可能会有更低的成果；但这种心态就是为什么网络如此不安全的原因......每个人都在说它并不那么重要......但是如果一些毫无戒心的用户在您的网站和他们的银行网站上使用相同的密码呢？？？

“攻击者拦截您的登录页面并在飞行中修改它的可能性有多大？”这不是概率问题，它发生与否取决于攻击者的选择。是的，MITM 确实在实践中发生。 “可能有很多较低的果实”几乎是一个人可以对任何事情做出的最弱的论点。真的，你能想出一个更弱的，不仅仅是简单的错误吗？此外，即使你的攻击者可以指望先摘下最低的水果，那还能说他们停在那里吗？

“机会”对我来说绝对是一个糟糕的选择。但是，由于其他攻击媒介，我认为您并没有获得太多实际的安全性。 MITM 攻击一次可能会危害您的用户一个用户（或 ISP），但 SQL 注入可能会同时危害您的所有使用。我认为，将您的安全时间花在您将获得最大收益的地方是有道理的，这可能不是 SSL 与非 SSL 登录页面。

如果有中间人攻击，你就会遇到更大的问题。首先，他们可以轻松地将“登录”链接更改为指向他们自己的攻击站点，或者更好的是，他们可以拦截 DNS 查找，使他们的站点在用户看来完全合法。在你说“哦，但是浏览器会警告用户”之前——不，他们不会。即使用户检查有效的 SSL 证书，也有办法解决这个问题。所以我猜你唯一的选择就是离线做所有的商务。

【参考方案2】：

在上述所有内容中遗漏的最大的事情之一是在主页上放置登录是一种普遍趋势（用户体验趋势中的巨大趋势）。

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

【讨论】：

不，次优选择是从 HTTP 站点页面链接到 HTTPS 登录页面。

【参考方案3】：

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

【讨论】：

但是，当用户点击指向（安全）登录页面的链接时，如果有任何恶作剧发生，SSL 协商会提醒他们。

@Mr Shiny and New：只有当他们仔细查看 URL 时。最好的选择是对您的整个网站进行 HTTPS 访问。

@Bart van Heukelom：整个站点的 HTTPs 仅适用于正确输入的 url 或正确保存的书签，不是吗？如果用户从不查看 url（或现代浏览器位置栏上的任何地方，它提供了您所连接的主机名的增强可见性），那么 SSL 是毫无意义的。

@Mr Shiny and New：确实如此，但是从 HTTP 到 HTTPS 的初始重定向，特别是如果用户随后将 HTTPS 版本添加为书签，对于黑客来说比每次登录链接时的窗口都小。点击。

@Bart：是的，用户可以很容易地为 HTTPS 登录页面添加书签，这就是我所做的，在验证登录 URL 正确之后，我只需要在添加书签时执行此操作。

【参考方案4】：

IE Blog 解释：严重错误 #1：非 HTTPS 登录页面（即使提交到 HTTPS 页面）

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

【讨论】：

但他们自己却不练习。

【参考方案5】：

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

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

这可能已经足够安全了。毕竟，如果您受到有针对性的中间人攻击，您不妨开始担心键盘记录器、您的本地 HOSTS 文件以及各种其他方式来找出涉及您的系统已被拥有的安全交易。

【讨论】：

"毕竟，如果您受制于有针对性的中间人，您不妨开始担心键盘记录器、您的本地 HOSTS 文件以及各种其他方式来了解您的安全交易，包括您的系统已被拥有”。我想知道您的系统最初是如何获得所有权的？

【参考方案6】：

对我（作为最终用户）而言，HTTPS 会话的价值不仅在于数据已加密，而且我已验证我正在输入超级机密的页面来自该位置我想要它。

在非 HTTPS 会话中使用表单会破坏这种保证。

（我知道 - 这只是表示表单受到 MITM 攻击的另一种说法）。

【参考方案7】：

这种事情在网络上到处都是，尤其是在登录是可选的网站中。然而，由于非常微妙的原因，它本质上是不安全的，并且给用户一种虚假的安全感。我想最近codinghorror.com上有一篇关于这个的文章。

危险在于，当您发送带有“https://xxx”的帖子目标的页面时，出现该引用的页面并不安全，因此攻击者可以在传输过程中对其进行修改以指向任何 URL攻击者的愿望。因此，如果我访问您的网站，我必须查看来源以验证我的凭据是否已发布到安全地址，并且该验证仅与该特定提交有关。如果我明天回来，我必须再次查看源代码，因为该页面的特定交付可能已受到攻击并且帖子目标被破坏 - 如果我不每次都验证，当我知道帖子目标被破坏时，它是太晚了 - 我已经将我的凭据发送到攻击者的 URL。

您应该只提供登录页面的链接；只要您登录，登录页面和之后的所有内容都应该是 HTTPS。而且，真的，没有理由不这样做； SSL 的负担在于初始协商；后续连接将使用 SSL 会话缓存，用于链接数据的对称加密实际上开销极低。

【参考方案8】：

不，从 HTTP 转到 HTTPS 不安全。请求的发起点和结果点必须是 HTTPS，才能建立和使用安全通道。

【讨论】：

问题是是否保存在HTTP上提供初始表单，并通过HTTPS发布数据。中途无法切换，但可以同时放置物品。

+1 这个答案是绝对正确的。如果表单是通过 HTTP 传递的，你甚至不能保证表单会通过 HTTPS 提交。

【参考方案9】：

This post 是关键。是的，如果用户的数据被发送给您，它就会安全地到达某个地方。但是没有理由相信某个地方会是您的站点。此时，攻击者不仅要监听各个方向的数据移动。他将成为用户会话的另一端。您的网站只会认为用户从不费心提交表单。

【参考方案10】：

是否有任何理由不在整个交易中使用 HTTPS？找不到很好的就用吧！

可以说它比切换协议更简单。

MITM 风险是真实存在的。

根据您的链接，用户“Helios”提出了一个很好的观点，即使用 100% HTTPS 对用户的困惑要小得多。

【讨论】：

我过去曾发现有人 /did/ 出于性能原因，这在当时是合法的。然而，尽管现在服务器和客户端的吞吐量和性能已经足够强大，但这样做的模式几乎被当作教条来教导，这是其中之一。

同意。那时，在算盘上做矢量图也很困难。 :-)

确实 :) 这是我不喜欢 CS 课程的原因之一，他们太落后了，所以他们教这些过时的方法，然后这是每个人的宗教信仰的一部分...... 认为 人，想想！ :)

过时了？您应该已经看到我们在本科 EE 实验室中使用的 20 磅电阻器！至少欧姆定律没有改变。然而。

我认为用户最好养成不在非 HTTPS 页面上输入登录信息的习惯。如果我看到 HTTP 并要求我登录，我只需点击登录，看看它是否进入 HTTPS，然后我实际上输入了一些信息。

【参考方案11】：

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

但是，如果原始的http表单被中间人攻击，并且https的回发地址被攻击者修改，那么您将不会收到任何警告。数据实际上仍将被加密，但中间人攻击者将能够解密（因为他首先向您发送了密钥）并读取数据。

此外，如果表单通过其他方式（脚本连接）发回内容，则可能会在表单发布之前通过网络发送未加密的数据（尽管任何好的网站都不会使用任何类型的敏感数据）。

【讨论】：

终于有个简单的答案

我还要补充一点，HSTS 解决了这个问题（好吧，除了第一个请求）