通过https从http表单提交可以接受吗？看起来应该是安全的，但是它允许中间人攻击（这是一个很好的讨论）。有些网站如mint.com允许您从http页面登录，但可以执行https发布。在我的网站上，请求的是拥有一个http登录页面，但能够安全登录。这是否不值得承担安全隐患，我是否应该让所有用户都进入安全页面登录（或使登录页面安全）？
Answers:
有什么理由不对整个交易使用HTTPS吗？如果找不到很好的产品，请使用它！
可以说它比交换协议更简单。
MITM风险是真实的。
跟随您的链接，用户“ Helios”提出了一个极好的观点，即使用100％HTTPS不会给用户造成混乱。
当表单以最简单的方式传输时，将表单从http页面发布到https页面确实会对表单中的数据进行加密。如果发生中间人攻击，浏览器会警告您。
但是，如果原始的HTTP表单受到中间人的攻击，并且https后发地址已被攻击者修改，那么您将不会收到任何警告。数据实际上仍将被加密，但是中间人攻击者将能够解密（因为他首先向您发送了密钥）并读取了数据。
另外，如果表单通过其他方式（脚本连接）将内容发送回去，则可能在表单发布之前通过有线方式发送未加密的数据（尽管任何好的网站都不会对任何敏感数据进行此操作） 。
这种事情在整个网络上都弹出，特别是在那些登录可选的站点中。但是，由于种种微妙的原因，它本质上是不安全的，并给用户一种虚假的安全感。我认为最近在horshoringhorror.com上有一篇有关此的文章。
危险是，当您发送的页面的发布目标为“ https：// xxx ”时，引用所在的页面并不安全，因此攻击者可以在传输过程中对其进行修改，以指向攻击者的任何URL。的愿望。因此，如果我访问您的网站，则必须查看源以验证我的凭据已被发布到安全地址，并且该验证仅与该特定提交有关。如果我明天返回，则必须再次查看源代码，因为该页面的特定交付可能已受到攻击并且发布目标已被颠覆-如果我不每次都进行验证，那么我知道发布目标已被颠覆时，为时已晚-我已经将凭据发送到攻击者的URL。
您只应提供指向登录页面的链接；只要您登录，登录页面及其后的所有内容都应为HTTPS。并且，实际上，没有理由不这样做；SSL的负担在于初始协商；随后的连接将使用SSL会话缓存，并且用于链接数据的对称加密实际上开销非常低。
Jay和Kiwi关于MITM攻击是正确的。但是，重要的是要注意，攻击者不必破坏表格并给出一些错误消息；攻击者可以改为插入JavaScript，以两次发送表单数据，一次发送给他，一次发送给您。
但是，老实说，您必须问，攻击者拦截登录页面并在运行中对其进行修改的机会是多少？与（a）在SSL会话上进行一次MITM攻击并希望用户按“ OK”继续的风险相比，它的风险如何？（b）在您最初重定向到SSL（例如，从http://example.com到https://example.com）并进行重定向到https://doma1n.com的情况下执行MITM ，该操作由攻击者控制; （c）您的网站某处存在XSS，XSRF或SQL注入漏洞。
是的，我建议在SSL下运行登录表单，没有任何理由不这样做。但是，如果不是这样的话，我也不会担心，可能还有很多悬而未决的结果。
上面的答案是从2008年开始的。此后，许多其他威胁变得显而易见。例如，访问来自不受信任的随机网络的站点，例如WiFi热点（附近的任何人都可以发起该攻击）。现在我要说的是，您绝对应该对登录页面进行加密，并进一步扩展整个站点。此外，现在有针对初始重定向问题（HTTP严格传输安全性）的解决方案。在开放Web应用安全项目提出了一些最佳做法指南可用。
这篇文章是关键。是的，如果将用户的数据发送给您，则该数据将安全地到达某处。但是没有理由相信您的网站会在某个地方。攻击者此时不仅要听各个方向的移动数据。他将成为用户会话的另一端。您的网站只会认为用户从未花时间提交表单。
不，从HTTP转到HTTPS是不安全的。请求的始发点和结果点必须是HTTPS，以便建立和使用安全通道。
每个建议您仅提供登录页面链接的人似乎都忘记了使用MITM攻击可以轻松更改该链接。
我认为这个问题的主要考虑因素是用户知道的URL和浏览器默认替换的协议方案（http :)。
在这种情况下，要确保加密通道的站点的正常行为是将http：// home-page重定向到https：// home-page。仍然存在欺骗/ MitM的机会，但是如果是通过DNS中毒，则风险不比使用https：URL开头的风险高。如果返回了另一个域名，则需要担心。
这可能足够安全。毕竟，如果您有针对性的MitM，那么您不妨开始担心键盘记录器，本地HOSTS文件以及各种其他方式来查找涉及系统的安全交易。