是的，这是一个安全问题，因为攻击者可能能够更改 HTML 代码。他可以更改表单的 action 属性以指向他自己的服务器。或者不那么明显更好：添加一些 javascript 代码，将密码镜像到他自己的服务器，而不会破坏对真实站点的登录。

不幸的是，Facebook 和 Twitter 都在这里树立了一个坏榜样。然而，Google Plus 会立即重定向到 https，所以还是有希望的。

你该怎么办？教育用户在将任何私人信息输入 Web 表单之前，他们需要检查地址栏的 https 和正确的域。

@Hendrik 说这是一个安全风险是正确的，因为非 HTTPS 登录页面可能允许攻击者在用户点击它之前修改提交链接，但是在你关于 webscarab 的问题中。

它（与其他代理一起）确实拦截了 HTTPS 流量（假设您已将其设置为所有协议的代理），因此这并不一定意味着流量将毫无疑问地穿越 Internet。如果帖子发往 HTTPS URL，那么它将被加密。

您通常可以判断何时使用其中一个拦截代理，因为您会收到有关证书不匹配的 SSL 错误消息（除非您已专门设置浏览器以信任来自代理的证书）

Rory 是完全正确的，但我想强调的是，您（和您的用户）应该非常警惕损坏的 SSL 证书。世界上有拦截 SSL 代理可以读取和修改您发送的任何内容，基于玩游戏的证书会导致这些错误。

如果您习惯于自己，或者更糟糕的是，您的用户接受证书错误，那么 SSL 的安全优势在数据包路径中的绝对任何人面前（例如，在同一家咖啡店或同一家酒店，更不用说IT部门）。

我对 webscarab 的了解为零，所以如果这与上下文无关，请原谅我，但是当您在数据包捕获中看到纯文本密码时，您应该始终保持怀疑。如果您在应用程序的后端发送明文密码，您最好非常确定您了解相关网络的安全属性。

SSL 既便宜又容易。在任何可能的地方打开它并快乐。

我还没有尝试过 webscarab，但我认为它通过生成未签名的 https 证书来拦截 HTTPS 流量。提交指向 https 资源的 http 登录页面应该是安全的。您可能在之前的调试会话中接受了 webscarab ssl 证书，并且您通常会收到有关它的警告。

但是，https 在很多方面都被破坏了。在https拦截的情况下，根本不需要生成新的SSL证书！为什么？

如果攻击者使用拦截代理 (MiTM)，他们可以巧妙地将所有 html 链接从 https:// uri 重写为 http://。现在您的站点不再使用 SSL 来加密敏感数据，并且用户不会收到任何 SSL 证书警告，因为它们没有被使用！

sslstrip是一个可以做到这一点的代理。

对此的对策可能是混淆您的链接，以使 sslstrip 无法重写您的https链接。想到 Javascript 和 CSS。