我有一个网站，它大部分都不是需要保护的东西。但是，该站点的一小部分仅适用于已登录的用户。
所以我的常规站点是 Http 并且登录用户的站点是通过 Https 的。
在我的常规 Http 站点上 - 我有一个指向 https 登录页面的链接，供那些需要访问该内容的用户使用。
我想知道这是否是一个安全问题——即有一个从 HTTP 页面到 HTTPS 页面的链接？
我能想到的唯一攻击是，是否存在某种中间人攻击，其中有人修改我的链接以指向一个具有与我相似的 URL 的虚假站点。
这是一个问题吗？我怎样才能减轻它？将我的常规网站也变成 https 的唯一方法是什么？
编辑：我的问题不是另一个问题的重复 - 另一个问题是关于切换到 http post login。我的问题完全不同——它是同一个站点的两个不同部分——一个需要登录，一个需要公开访问。我在问是否可以保留第一部分 https（用于登录和登录后）并保留另一部分 http。
是的，它是不安全的。
最简单的攻击方法是 sslstrip，这是一种执行中间人并自动将 https 链接替换为 http 链接的工具。
正确执行此操作的唯一安全方法是在整个网站上使用 https，并激活 HSTS。
请注意，即使对于您未登录的用户，https 也很有用，例如防止第三方（如 ISP）在未经您同意的情况下在您的网站中插入广告。
这里的主要威胁是中间人攻击。
任何从http://example.comto导航的用户https://example.com/secure/login都可能是sslstrip或可能被重定向到网络钓鱼域 - https://example.org。
这也意味着 HSTS 不能用于缓解 sslstrip。HSTS 将确保一旦浏览器通过 HTTPS 连接，在策略过期之前，它永远无法与该域建立纯 HTTP 连接。请注意，“那个域”是指您的实际域，或者假装是您站点的纯 HTTP 版本的 MITM 控制域。
如果您的安全内容与您的不安全内容在同一个域中，那么这意味着即使您在所有敏感 cookie 上设置了安全标志，cookie 仍然可能被 MITM 毒害。例如，在会话固定攻击中，对 CSRF 双重提交 cookie 控制的攻击，或者在您使用 cookie 向页面显示原始内容的情况下，可能会发生 XSS 攻击。这是因为 cookie 设置为 onhttp://example.com并且https://example.com在服务器看来是相同的，因为 Secure 标志不会在每个 HTTP 请求中发送给服务器以区分它们。
我建议在站点范围内使用 HTTPS，并通过预加载实现 HSTS 策略。
由于可以在 http 模式下访问您的站点，因此我假设它不包含高度敏感的内容。选择 HTTP 还是 HTTPS 是一个以安全换取性能的问题：
根据经验，如果您可以提供足够的资源，请使用 HTTPS；如果数据价值较低，请使用 HTTP。
可以允许将 HTTP 用于普通页面，将 HTTPS 用于敏感页面，例如提供的凭证交换：
您必须注意的是，一旦会话使用了不安全的 cookie（HTTP 模式），您就不应该相信该会话可以访问敏感信息。
所以这是正确的：HTTP 咨询 => 链接到 HTTPS 以进行登录 => 登录后新会话 => HTTP 咨询 - 整体安全性为中低，因为会话 cookie 不安全，您只保护凭据
但这很糟糕：HTTPS登录=>非敏感页面的HTTP咨询=>敏感数据的HTTPS咨询/修改
因为这里会话的安全级别已经降到了HTTP，仍然用于敏感操作。
最小值应该是：
... => HTTP 操作 => 凭证或安全 cookie 的 HTTPS 控制 => 新会话 => HTTPS 操作 ...
这里最大的风险是你应该告诉你的用户登录页面是特殊的，并且他们应该控制小挂锁的存在并且url 在正确的域中。风险在这里：
=> 攻击者已经获得了用户允许的所有访问权限
TL/DR：只有在 HTTPS 中包含网站的一部分（包括登录页面）才可以接受：