登录必须是 https 页面

Posted 2023-02-25

【中文标题】登录必须是 https 页面

【英文标题】：Must logins be a https page

【发布时间】：2011-05-17 14:08:43

【问题描述】：

过去多位安全专家说过，登录页面应该在 ssl https 上。那么，如果我的登录是一个显示在所有页面上的块怎么办。这是否意味着我的整个网站都必须是 https 的？

我读到可以将表单放在 http 上但将其发布到 https，但我读到有人说它可以被中间人利用。有人可以证实这一点吗？对于可以确认这一点的人，我有 100 分的赏金（并帮助我提供如何安全解决此问题的实用答案）。我的登录表单在每个页面上，我需要在 https 上制作整个网站吗？请随时质疑我在这里所说的任何内容。它们只是我读过但没有经验也没有亲自尝试过的东西。

编辑：对于那些询问的人，当我发布问题时，我尝试设置赏金，但系统不允许我这样做。我查看了常见问题解答，发现可以在发布问题 2 天后发布赏金。这就是为什么你还没有看到赏金。但我不会选择答案，直到我在 2 天内设置赏金。很抱歉有任何混淆。

【问题讨论】：

问题已经 6 分钟了，还不能添加赏金（现在提供赏金还为时过早）。

在 SecuritySE 上查看 this question。

【参考方案1】：

我读到可以将表单放在 http 上但将其发布到 https，但我读到有人说它可以被中间人利用。有人可以确认吗？

是的。该表单是通过 HTTP 提供的，因此中间人可以对其进行更改（例如，它会在表单提交之前将凭据发送到他们自己的服务器）。

如何安全地解决这个问题的实用答案

如果安全真的很重要 - 对整个站点使用 HTTPS。即使在发送密码之后，如果您返回 HTTP，cookie 也可能被盗（参见Firesheep）

如果安全性没有那么重要，那么不要将登录表单放在每个页面上。只需一个指向登录页面的链接即可。

【讨论】：

大约一个小时前这里有另一个答案，但我猜所有者因为反对票而删除了它。他说 facebook 使用 http 作为主页，但将表单发布到 https，就像我在问题中提出的那样。我检查了他们的代码，他们确实做到了https://login.facebook.com/login.php 所以.. 是我们遗漏了什么，还是他们在这里打错了电话？我只是想知道，因为 facebook 是大狗，如果它确实不安全，他们应该知道这些东西吗？有没有cmets？

Facebook 打错电话了（这对他们来说与安全或隐私相关的事情并不少见）。 Firesheep（在答案中链接）在 SSL 部分之后证明了其安全性缺陷，但 pre-SSL 部分也容易受到攻击。

Facebook 帐户经常遭到入侵，但他们对此无能为力。不过，对所有流量使用 HTTPS 可能会削弱他们的基础设施。

请参阅sslstrip，了解针对托管在不安全页面上的 HTTPS 表单的中间人攻击示例。

【参考方案2】：

简单回答“是”，您的登录页面和其他网站应该通过 SSL 提供服务

以下是 SSL 实施常见问题解答中的原因：

Can I put my Login form to HTTP and target my form to HTTPS? Is it secure switch back to HTTP after login over HTTPS?

【讨论】：

说一切都必须是 SSL 就像说每个人都应该使用 linux、firefox 作为 web 浏览器以及俄罗斯制造的汽车......创建 web 应用程序和网站是关于妥协，我想要最好的保护我的应用并保护用户访问凭据的方式。但我仍然无法得到答案。

我也给了这个答案。链接解释了很多，唯一我不喜欢的是大多数答案是“不，你不应该”或“不，你不能”我希望有更多的解决方案和更少的阻碍。

【参考方案3】：

好吧，如果您不使用 SSL 登录，用户的密码可能会泄露给任何有能力监听客户端-服务器通信（主要是读取数据流）的人。 （这不好^^）

正如上面 goreSplatter 所说，您可以轻松地将表单目标设置为安全端点（即https://site.com/login），并且安全连接将用于发送用户的凭据和接收响应。

然后大多数网站继续通过基本 HTTP 进行通信，这“仅”将其用户暴露于会话劫持的风险（中间人读取他们的会话标识符/签名/nonce/whatever 然后假装是认证的客户端，因此如果他成功了，他可以操纵客户端的受保护资源，但这种方法不允许“窃取整个帐户”）。这通常被认为是次要威胁，并且由于与 SSL 通信相关的开销，所有请求的安全连接仅用于关键应用程序（例如在线银行）。

最后，回答您的问题：不，只有发送敏感数据的传输必须是安全的。

【讨论】：

这种方法的问题在于，劫持会话在许多方面与“窃取整个帐户”相同......

【参考方案4】：

如果您希望您的数据安全，您必须在整个网站上使用 SSL（认证）。但是您不需要 SSL 来保证您的密码安全。例如，您可以使用 openID、facebook connect、twitter 登录来为您处理这部分。这种方式永远不会以纯文本形式通过网络发送密码。

【讨论】：

使用 OpenID 确实是一个优雅的解决方案，感谢分享

【参考方案5】：

您可以选择重新设计 UI 概念吗？想法：在每个页面上都有信息登录 UI，但没有实际的登录控件。您的新 info 控件将列出：

Logged In As <user_name> 或 Not Logged In Login 或 Logout 链接取决于状态

然后链接会显示一个登录弹出页面，其内容是完全安全的。

这种方法可以让您接近您已经拥有的东西（每个页面上的一些登录功能），但路由/分层的方式是您的身份验证完全通过 SSL 保护。

【参考方案6】：

例如，GMAIL 在配置中有一个选项可以启用 SSL。 Facebook、Twitter 和所有社交媒体都没有 SSL 或未启用。

我认为，如果您真的希望您的网站免受所有恶意软件（无论是否是机器人）的影响，那么您最好使用 SSL。 （但如果启用了 SSL，您就有被劫持的风险）否则您可以尝试使用 js 硬编码来混淆表单数据。

上面的好答案，加上一切，让你对此事有自己的想法！

祝你好运。

【参考方案7】：

我读到可以将表单放在 http 上但将其发布到 https，但我读到有人说它可以被中间人利用。

没有。 <form> 的目标是正在使用的浏览器执行的新调用。

如果 URL http://example.com/ 已被访问并且页面的内容已被浏览器呈现，则关闭不安全的连接（是的。它可能保持打开 [Keep-Alive]。但是对该 URL 的请求已完成）。

对于站点的登录目标https://example.com/，将使用不同的服务器端口（通常为 443）在服务器和客户端之间协商 SSL 会话，并且不使用/传输来自前一页的数据（可能是“Referer”）在安全连接建立之后。

我读到可以将表单放在 http 上但将其发布到 https，但我读到有人说它可以被中间人利用。有人可以确认吗？

是的。表单通过 HTTP 提供，因此中间人可以对其进行更改（例如，在表单提交之前将凭据发送到他们自己的服务器）。

在受感染的网站上，内容是否受到保护并不重要。网站的内容可以通过 SSL 传递，但代码仍然可能受到破坏。

此外，cookie 也可能被盗。但它们只是文本。这就是您的网站对“文本”所做的事情，这很重要。如果你依赖“浏览器”告诉你的脚本，你的应用程序是不安全的。使用 cookie 验证（基于 IP、基于浏览器，无论基于什么），这样 cookie 就不会被“窃取”。

在您的用户发送数据时使用受 SSL 保护的网站，这值得保护。评论博客文章不是我会通过建立 SSL 连接来给我的服务器施加压力的事情...

【讨论】：

在中间人攻击中，该站点并未受到威胁。客户端和服务器之间有连接。 SSL 可防止代码受到损害，因为它提供身份验证和加密。 SSL 提供加密功能，可防止 cookie 被盗。

同意。然而，DNS 欺骗可能会危害网站并且也可以通过 SSL 工作。

欺骗者如何获得由浏览器信任的授权机构签署的重定向主机名的 SSL 证书？

-1 "不。

【参考方案8】：

即使您尝试将登录块放在使用 https 的 iframe 中，中间人攻击也可能轻松更改该 iframe 的 src，因此您可以将登录框设置为登录链接（使用 https 登录页面），否则您将需要更多资源来为所有具有登录框的网页使用 ssl 运行您的网站...

【讨论】：

如果我们允许 MITM 将 src 属性更改为他选择的 iframe - 为什么他不能更改登录链接上的 href？

您可能会看到一些网站警告您“确保网址以 https 开头”，因此至少用户（按照说明操作）仍然可以在他们的地址栏中看到 https 网址，而他们可以不知道 iframe 是否在 ssl 下！ .对于那些没有注意到的人来说，这是他们的错误......