Is it acceptable to submit from an http form through https? It seems like it should be secure, but it allows for a man in the middle attack (here is a good discussion). There are sites like mint.com that allow you to sign-in from an http page but does an https post. In my site, the request is to have an http landing page but be able to login securely. Is it not worth the possible security risk and should I just make all users go to a secure page to login (or make the landing page secure)?
是否可以通过https从http表单提交?它似乎应该是安全的,但它允许一个人在中间攻击(这是一个很好的讨论)。有一些网站,如mint.com,允许您从http页面登录,但做https帖子。在我的网站中,请求是具有http登录页面,但能够安全登录。是否值得冒可能的安全风险,我是否应该让所有用户进入安全页面登录(或使登录页面安全)?
11 个解决方案
#1
33
Is there any reason not to use HTTPS for the entire transaction? If you can't find a very good one, use it!
是否有任何理由不在整个交易中使用HTTPS?如果找不到一个好的,请使用它!
-
It's arguably simpler than switching protocols.
它可以说比切换协议更简单。
-
The MITM risk is real.
MITM的风险是真实的。
-
Following your link, the user "Helios" makes an excellent point that using 100% HTTPS is far less confusing to the user.
在您的链接之后,用户“Helios”非常重要,即使用100%HTTPS对用户来说远没有那么混乱。
#2
50
Posting a form from an http page to an https page does encrypt the data in the form when it is transmitted in the most simple terms. If there is a man-in-the-middle attack, the browser will warn you.
将表单从http页面发布到https页面会在以最简单的术语传输时对表单中的数据进行加密。如果有中间人攻击,浏览器会发出警告。
However, if the original http form was subjected to man-in-the-middle and the https post-back address was modified by the attacker, then you will get no warning. The data will still actually be encrypted, but the man-in-the-middle attacker would be able to decrypt (since he sent you the key in the first place) and read the data.
但是,如果原始http表单受到中间人的攻击并且攻击者修改了https回发后地址,那么您将不会收到任何警告。数据仍然实际上是加密的,但是中间人攻击者能够解密(因为他首先发送了密钥)并读取数据。
Also, if the form is sending things back through other means (scripted connections) there may be a possibility of unencrypted data being sent over the wire before the form is posted (although any good website would never do this with any kind of sensitive data).
此外,如果表单通过其他方式(脚本连接)发送回来,则可能有可能在发布表单之前通过网络发送未加密的数据(尽管任何好的网站都不会对任何类型的敏感数据执行此操作) 。
#3
16
This kind of thing is popping up all over the net, especially in sites for which login is optional. However, it's inherently unsafe, for quite subtle reasons, and gives the user a false sense of security. I think there was an article about this recently on codinghorror.com.
这种事情在网络上突然出现,特别是在登录是可选的网站中。然而,由于非常微妙的原因,它本质上是不安全的,并且给用户一种虚假的安全感。我认为最近有一篇关于codinghorror.com的文章。
The danger is that while you sent your page with a post target of "https://xxx", the page in which that reference occurs is not secure, so it can be modified in transit by an attacker to point to any URL the attacker wishes. So if I visit your site, I must view the source to verify my credentials are being posted to a secure address, and that verification has relevance only for that particular submit. If I return tomorrow, I must view source again, since that particular delivery of the page may have been attacked and the post target subverted - if I don't verify every single time, by the time I know the post target was subverted, it's too late - I've already sent my credentials to the attacker's URL.
危险在于,当您发送的页面的帖子目标为“https:// xxx”时,发生该引用的页面不安全,因此攻击者可以在传输过程中对其进行修改以指向攻击者的任何URL祝愿。因此,如果我访问您的网站,我必须查看来源以验证我的凭据是否已发布到安全地址,并且该验证仅与该特定提交相关。如果我明天回来,我必须再次查看来源,因为页面的特定传递可能已被攻击并且后期目标被破坏 - 如果我不是每次都验证,那么当我知道后期目标被破坏时,它是太晚了 - 我已经将我的凭据发送给了攻击者的URL。
You should only provide a link to the login page; and the login page and everything thereafter should be HTTPS for as long as you are logged in. And, really, there is no reason not to; the burden of SSL is on the initial negotiation; the subsequent connections will use SSL session caching and the symmetric crypto used for the link data is actually extremely low overhead.
您应该只提供登录页面的链接;只要您已登录,登录页面及其后的所有内容都应该是HTTPS。而且,实际上,没有理由不这样做; SSL的负担是在最初的谈判中;后续连接将使用SSL会话缓存,而用于链接数据的对称加密实际上是非常低的开销。
#4
10
IE Blog explains: Critical Mistake #1: Non-HTTPS Login pages (even if submitting to a HTTPS page)
IE博客解释:严重错误#1:非HTTPS登录页面(即使提交到HTTPS页面)
- How does the user know that the form is being submitted via HTTPS? Most browsers have no such UI cue.
- How could the user know that it was going to the right HTTPS page? If the login form was delivered via HTTP, there's no guarantee it hasn't been changed between the server and the client.
用户如何知道表单是通过HTTPS提交的?大多数浏览器都没有这样的UI提示。
用户怎么知道它会进入正确的HTTPS页面?如果登录表单是通过HTTP提供的,则无法保证服务器和客户端之间没有更改。
#5
6
Jay and Kiwi are right about the MITM attack. However, its important to note that the attacker doesn't have to break the form and give some error message; the attacker can instead insert JavaScript to send the form data twice, once to him and once to you.
Jay和Kiwi对MITM攻击是正确的。但是,重要的是要注意攻击者不必破坏表单并给出一些错误消息;攻击者可以改为插入JavaScript来两次发送表单数据,一次发送给他,一次发送给你。
But, honestly, you have to ask, what's the chance of an attacker intercepting your login page and modifying it in flight? How's it compare to the risk of (a) doing a MITM attack strait on the SSL session, and hoping the user presses "OK" to continue; (b) doing the MITM on your initial redirect to SSL (e.g., from http://example.com to https://example.com) and redirecting to https://doma1n.com instead, which is under the attacker's control; (c) You having a XSS, XSRF, or SQL injection flaw somewhere on your site.
但是,老实说,你必须问,攻击者拦截你的登录页面并在飞行中修改它的可能性是多少?它是如何与(a)在SSL会话上进行MITM攻击的风险相比,并希望用户按“OK”继续; (b)在初始重定向到SSL时执行MITM(例如,从http://example.com到https://example.com)并重定向到https://doma1n.com,这是受攻击者的控制; (c)您的网站上有某个XSS,XSRF或SQL注入缺陷。
Yes, I'd suggest running the login form under SSL, there isn't any reason not to. But I wouldn't worry much if it weren't, there are probably much lower hanging fruit.
是的,我建议在SSL下运行登录表单,没有任何理由不这样做。但如果不是,我不会担心,可能会有更低的悬挂果实。
Update
The above answer is from 2008. Since then, a lot of additional threats have become apparent. E.g., access sites from random untrusted networks such as WiFi hotspots (where anyone nearby may be able to pull off that attack). Now I'd say yes, you definitely should encrypt your login page, and further your entire site. Further, there are now solutions to the initial redirect problem (HTTP Strict Transport Security). The Open Web Application Security Project makes several best practices guides available.
上述答案来自2008年。从那时起,许多其他威胁变得明显。例如,从随机不受信任的网络(例如WiFi热点)访问站点(附近的任何人都可能能够实现该攻击)。现在我说是的,你绝对应该加密你的登录页面,并进一步整个网站。此外,现在有解决初始重定向问题(HTTP严格传输安全性)的解决方案。 Open Web Application Security Project提供了几个最佳实践指南。
#6
2
This post is the key one. Yes, if the user's data is sent to you, it will have arrived somewhere securely. But there is no reason to believe that somewhere will be your site. The attacker isn't just going to get to listen to the data moving in each direction at this point. He'll be the other end of the user's session. The your site is just going to think the user never bothered to submit the form.
这篇文章是关键的一篇。是的,如果用户的数据发送给您,它将安全地到达某个地方。但是没有理由相信某个地方会是你的网站。此时攻击者不仅要听取每个方向移动的数据。他将成为用户会话的另一端。您的网站只是认为用户从不打扰提交表单。
#7
2
For me (as an end-user), the value of an HTTPS session is not only that the data is encrypted, but that I have verification that the page I'm typing my super-secrets into has come from the place I want it to.
对我来说(作为最终用户),HTTPS会话的价值不仅仅是数据被加密,而且我已经验证我正在输入我的超级秘密的页面来自我想要它的地方至。
Having the form in a non-HTTPS session defeats that assurance.
在非HTTPS会话中使表单失败了。
(I know - this is just another way of saying that the form is subject to an MITM attack).
(我知道 - 这只是说这种形式受到MITM攻击的另一种方式)。
#8
1
No, it's not secure to go from HTTP to HTTPS. The originating and resulting points of the request must be HTTPS for the secure channel to be established and utilized.
不,从HTTP到HTTPS都不安全。请求的始发点和结果点必须是HTTPS才能建立和使用安全信道。
#9
1
Everyone suggesting that you provide only a link to the login page seems to be forgetting that the link could easily be changed using a MITM attack.
每个人都建议您只提供登录页面的链接似乎忘记了使用MITM攻击可以轻松更改链接。
#10
1
One of the biggest things missed out in all of the above is that there is a general trend to place a login on a home page (Huge trend in User Experience Trends).
上述所有内容中最大的缺点之一就是总体趋势是在主页上进行登录(用户体验趋势中的巨大趋势)。
The big problem here is that Google does not like to search secure pages with good reason, so all those Devs who are wondering why not make it all secure, well if you want your page invisible to Google, secure it all. Else, the second best option to post from http to https is the lesser of two evils at this point?
这里的一个大问题是谷歌不喜欢有充分理由搜索安全页面,因此所有那些想知道为什么不安全的开发人员,如果你想让你的页面对谷歌不可见,那就确保一切安全。否则,从http发布到https的第二个最佳选择是此时两个邪恶中的较小者?
#11
-2
I think the main consideration of this question has to do with the URL that users know and the protocol scheme (http:)that browsers substitute by default.
我认为这个问题的主要考虑因素与用户知道的URL和浏览器默认替代的协议方案(http :)有关。
In that case, the normal behavior of a site that wants to ensure an encrypted channel is to have the http://home-page redirect to https://home-page. There is still a spoofing / MitM opportunity, but if it is by DNS poisoning, the risk is no higher than if one starts out with the https: URL. If a different domain name comes back, you need to worry then.
在这种情况下,想要确保加密频道的站点的正常行为是将http://主页重定向到https:// home-page。仍然存在欺骗/ MitM机会,但如果是DNS中毒,则风险不会高于使用https:URL开始的风险。如果返回不同的域名,则需要担心。
This is probably safe enough. After all, if you are subject to a targetted MitM, you might as well start worrying about keyboard loggers, your local HOSTS file, and all sorts of other ways of finding out about your secure transactions involving your system already being owned.
这可能足够安全。毕竟,如果您受到目标MitM的影响,您可能会开始担心键盘记录器,本地HOSTS文件以及各种其他方式来查找涉及您的系统已经拥有的安全交易。
#1
33
Is there any reason not to use HTTPS for the entire transaction? If you can't find a very good one, use it!
是否有任何理由不在整个交易中使用HTTPS?如果找不到一个好的,请使用它!
-
It's arguably simpler than switching protocols.
它可以说比切换协议更简单。
-
The MITM risk is real.
MITM的风险是真实的。
-
Following your link, the user "Helios" makes an excellent point that using 100% HTTPS is far less confusing to the user.
在您的链接之后,用户“Helios”非常重要,即使用100%HTTPS对用户来说远没有那么混乱。
#2
50
Posting a form from an http page to an https page does encrypt the data in the form when it is transmitted in the most simple terms. If there is a man-in-the-middle attack, the browser will warn you.
将表单从http页面发布到https页面会在以最简单的术语传输时对表单中的数据进行加密。如果有中间人攻击,浏览器会发出警告。
However, if the original http form was subjected to man-in-the-middle and the https post-back address was modified by the attacker, then you will get no warning. The data will still actually be encrypted, but the man-in-the-middle attacker would be able to decrypt (since he sent you the key in the first place) and read the data.
但是,如果原始http表单受到中间人的攻击并且攻击者修改了https回发后地址,那么您将不会收到任何警告。数据仍然实际上是加密的,但是中间人攻击者能够解密(因为他首先发送了密钥)并读取数据。
Also, if the form is sending things back through other means (scripted connections) there may be a possibility of unencrypted data being sent over the wire before the form is posted (although any good website would never do this with any kind of sensitive data).
此外,如果表单通过其他方式(脚本连接)发送回来,则可能有可能在发布表单之前通过网络发送未加密的数据(尽管任何好的网站都不会对任何类型的敏感数据执行此操作) 。
#3
16
This kind of thing is popping up all over the net, especially in sites for which login is optional. However, it's inherently unsafe, for quite subtle reasons, and gives the user a false sense of security. I think there was an article about this recently on codinghorror.com.
这种事情在网络上突然出现,特别是在登录是可选的网站中。然而,由于非常微妙的原因,它本质上是不安全的,并且给用户一种虚假的安全感。我认为最近有一篇关于codinghorror.com的文章。
The danger is that while you sent your page with a post target of "https://xxx", the page in which that reference occurs is not secure, so it can be modified in transit by an attacker to point to any URL the attacker wishes. So if I visit your site, I must view the source to verify my credentials are being posted to a secure address, and that verification has relevance only for that particular submit. If I return tomorrow, I must view source again, since that particular delivery of the page may have been attacked and the post target subverted - if I don't verify every single time, by the time I know the post target was subverted, it's too late - I've already sent my credentials to the attacker's URL.
危险在于,当您发送的页面的帖子目标为“https:// xxx”时,发生该引用的页面不安全,因此攻击者可以在传输过程中对其进行修改以指向攻击者的任何URL祝愿。因此,如果我访问您的网站,我必须查看来源以验证我的凭据是否已发布到安全地址,并且该验证仅与该特定提交相关。如果我明天回来,我必须再次查看来源,因为页面的特定传递可能已被攻击并且后期目标被破坏 - 如果我不是每次都验证,那么当我知道后期目标被破坏时,它是太晚了 - 我已经将我的凭据发送给了攻击者的URL。
You should only provide a link to the login page; and the login page and everything thereafter should be HTTPS for as long as you are logged in. And, really, there is no reason not to; the burden of SSL is on the initial negotiation; the subsequent connections will use SSL session caching and the symmetric crypto used for the link data is actually extremely low overhead.
您应该只提供登录页面的链接;只要您已登录,登录页面及其后的所有内容都应该是HTTPS。而且,实际上,没有理由不这样做; SSL的负担是在最初的谈判中;后续连接将使用SSL会话缓存,而用于链接数据的对称加密实际上是非常低的开销。
#4
10
IE Blog explains: Critical Mistake #1: Non-HTTPS Login pages (even if submitting to a HTTPS page)
IE博客解释:严重错误#1:非HTTPS登录页面(即使提交到HTTPS页面)
- How does the user know that the form is being submitted via HTTPS? Most browsers have no such UI cue.
- How could the user know that it was going to the right HTTPS page? If the login form was delivered via HTTP, there's no guarantee it hasn't been changed between the server and the client.
用户如何知道表单是通过HTTPS提交的?大多数浏览器都没有这样的UI提示。
用户怎么知道它会进入正确的HTTPS页面?如果登录表单是通过HTTP提供的,则无法保证服务器和客户端之间没有更改。
#5
6
Jay and Kiwi are right about the MITM attack. However, its important to note that the attacker doesn't have to break the form and give some error message; the attacker can instead insert JavaScript to send the form data twice, once to him and once to you.
Jay和Kiwi对MITM攻击是正确的。但是,重要的是要注意攻击者不必破坏表单并给出一些错误消息;攻击者可以改为插入JavaScript来两次发送表单数据,一次发送给他,一次发送给你。
But, honestly, you have to ask, what's the chance of an attacker intercepting your login page and modifying it in flight? How's it compare to the risk of (a) doing a MITM attack strait on the SSL session, and hoping the user presses "OK" to continue; (b) doing the MITM on your initial redirect to SSL (e.g., from http://example.com to https://example.com) and redirecting to https://doma1n.com instead, which is under the attacker's control; (c) You having a XSS, XSRF, or SQL injection flaw somewhere on your site.
但是,老实说,你必须问,攻击者拦截你的登录页面并在飞行中修改它的可能性是多少?它是如何与(a)在SSL会话上进行MITM攻击的风险相比,并希望用户按“OK”继续; (b)在初始重定向到SSL时执行MITM(例如,从http://example.com到https://example.com)并重定向到https://doma1n.com,这是受攻击者的控制; (c)您的网站上有某个XSS,XSRF或SQL注入缺陷。
Yes, I'd suggest running the login form under SSL, there isn't any reason not to. But I wouldn't worry much if it weren't, there are probably much lower hanging fruit.
是的,我建议在SSL下运行登录表单,没有任何理由不这样做。但如果不是,我不会担心,可能会有更低的悬挂果实。
Update
The above answer is from 2008. Since then, a lot of additional threats have become apparent. E.g., access sites from random untrusted networks such as WiFi hotspots (where anyone nearby may be able to pull off that attack). Now I'd say yes, you definitely should encrypt your login page, and further your entire site. Further, there are now solutions to the initial redirect problem (HTTP Strict Transport Security). The Open Web Application Security Project makes several best practices guides available.
上述答案来自2008年。从那时起,许多其他威胁变得明显。例如,从随机不受信任的网络(例如WiFi热点)访问站点(附近的任何人都可能能够实现该攻击)。现在我说是的,你绝对应该加密你的登录页面,并进一步整个网站。此外,现在有解决初始重定向问题(HTTP严格传输安全性)的解决方案。 Open Web Application Security Project提供了几个最佳实践指南。
#6
2
This post is the key one. Yes, if the user's data is sent to you, it will have arrived somewhere securely. But there is no reason to believe that somewhere will be your site. The attacker isn't just going to get to listen to the data moving in each direction at this point. He'll be the other end of the user's session. The your site is just going to think the user never bothered to submit the form.
这篇文章是关键的一篇。是的,如果用户的数据发送给您,它将安全地到达某个地方。但是没有理由相信某个地方会是你的网站。此时攻击者不仅要听取每个方向移动的数据。他将成为用户会话的另一端。您的网站只是认为用户从不打扰提交表单。
#7
2
For me (as an end-user), the value of an HTTPS session is not only that the data is encrypted, but that I have verification that the page I'm typing my super-secrets into has come from the place I want it to.
对我来说(作为最终用户),HTTPS会话的价值不仅仅是数据被加密,而且我已经验证我正在输入我的超级秘密的页面来自我想要它的地方至。
Having the form in a non-HTTPS session defeats that assurance.
在非HTTPS会话中使表单失败了。
(I know - this is just another way of saying that the form is subject to an MITM attack).
(我知道 - 这只是说这种形式受到MITM攻击的另一种方式)。
#8
1
No, it's not secure to go from HTTP to HTTPS. The originating and resulting points of the request must be HTTPS for the secure channel to be established and utilized.
不,从HTTP到HTTPS都不安全。请求的始发点和结果点必须是HTTPS才能建立和使用安全信道。
#9
1
Everyone suggesting that you provide only a link to the login page seems to be forgetting that the link could easily be changed using a MITM attack.
每个人都建议您只提供登录页面的链接似乎忘记了使用MITM攻击可以轻松更改链接。
#10
1
One of the biggest things missed out in all of the above is that there is a general trend to place a login on a home page (Huge trend in User Experience Trends).
上述所有内容中最大的缺点之一就是总体趋势是在主页上进行登录(用户体验趋势中的巨大趋势)。
The big problem here is that Google does not like to search secure pages with good reason, so all those Devs who are wondering why not make it all secure, well if you want your page invisible to Google, secure it all. Else, the second best option to post from http to https is the lesser of two evils at this point?
这里的一个大问题是谷歌不喜欢有充分理由搜索安全页面,因此所有那些想知道为什么不安全的开发人员,如果你想让你的页面对谷歌不可见,那就确保一切安全。否则,从http发布到https的第二个最佳选择是此时两个邪恶中的较小者?
#11
-2
I think the main consideration of this question has to do with the URL that users know and the protocol scheme (http:)that browsers substitute by default.
我认为这个问题的主要考虑因素与用户知道的URL和浏览器默认替代的协议方案(http :)有关。
In that case, the normal behavior of a site that wants to ensure an encrypted channel is to have the http://home-page redirect to https://home-page. There is still a spoofing / MitM opportunity, but if it is by DNS poisoning, the risk is no higher than if one starts out with the https: URL. If a different domain name comes back, you need to worry then.
在这种情况下,想要确保加密频道的站点的正常行为是将http://主页重定向到https:// home-page。仍然存在欺骗/ MitM机会,但如果是DNS中毒,则风险不会高于使用https:URL开始的风险。如果返回不同的域名,则需要担心。
This is probably safe enough. After all, if you are subject to a targetted MitM, you might as well start worrying about keyboard loggers, your local HOSTS file, and all sorts of other ways of finding out about your secure transactions involving your system already being owned.
这可能足够安全。毕竟,如果您受到目标MitM的影响,您可能会开始担心键盘记录器,本地HOSTS文件以及各种其他方式来查找涉及您的系统已经拥有的安全交易。