Php 登录后，所有页面是否应为https？

这将有点难以解释，但我会尽我最大的努力

有一个网站，每个页面上都有带有用户名/密码字段的登录表单。这些页面未使用SSL。用户填写用户名/密码并提交表单后，表单将发送到https身份验证页面

关于这种情况，我有几个问题

向https页面提交表单时，数据是否加密？或者仅在从https页面转到（我假设仅从）之后？

如果第一个问题的答案是梯形图，这是否意味着我需要对所有页面使用https，因为登录表单将从此处重定向？

在用户使用https进行身份验证之后，能否将用户重定向回http并继续使用会话数据？还是用户应该保留https？

将用户保留在https中是否更好/更糟

非常感谢你的帮助
大都会

结论

好吧，在考虑了一段时间之后，我决定把整件事都做成https@马修+@Rook，你们的回答都很好，我认为你们都有很好的观点。如果我处在一个不同的情况下，我可能会采取不同的做法，但以下是我做出这一切的原因

控制页面请求会更容易，因为我只需要使用https。

我不太关心性能（在另一种情况下，我可能会）

我不需要怀疑用户数据是否在所有地方都得到了保护

我将遵循Rook所述的OWASP指南

根据在任何时候都不能通过HTTP使用经过身份验证的会话id。因此，您通过HTTP创建了一个会话，然后该会话被验证，然后您违反了OWASP前10条，并且您允许您的用户容易受到攻击

我建议设置该选项。这是一个很糟糕的名称，但它强制cookie只能是https。这不应该与“Httponly cookies”混淆，后者是一个不同的标志，有助于减轻xss的影响

为了确保您的用户安全，我会一直强制使用HTTPS。SSL是一种非常轻量级的协议，如果遇到资源问题，那么考虑链接您的HTTPS策略。

对。如果操作URL是https，则表单数据将被加密

由于#1，您不必将页面设置为https，但您可能会收到混合内容警告。当然，中间人攻击者可以操纵登录页面指向不同的操作URL

这是你的决定。显然，通过HTTP传输的任何数据，无论是cookie（包括会话cookie）还是用户数据，都可以被拦截和操纵

同样，这是基于性能和安全性的权衡

---

除了Rook所说的之外，从http向https提交表单也是一种风险，原因如下：

在人们输入用户名和密码的页面上没有“锁定”图标，因此他们无法知道自己的详细信息已被加密（除非“信任你”）

如果有人劫持了你的页面，你的用户将无法知道他们将要键入用户名和密码并被重定向到恶意页面（这在某种程度上是#1的必然结果）

这是一种比http cookie拦截简单得多的攻击，因此实际上风险更大

---

但是Rook的观点很重要：你不应该混合使用http和https流量。在我们的网站上，一旦您登录，从那时起，所有内容都是https。

除了前面的答案之外，因为出于性能原因，人们倾向于从https转到HTTP，这可能会引起兴趣。其主要信息是：

SSL/TLS在计算上不可用 不再贵了

---

为什么这个网站除了登录外一直在使用http？我必须假设他们正在使用会话？是的，正如我所说，这是一种权衡。可以拦截并窃取StackOverflow会话cookie。他们决定愿意冒这种风险，因为这是一种非常常见的违反owasp的行为。同样，100%安全（@Metropolis:因为他们对会话劫持没有过度的偏执。有时绝对安全是重要的，有时却不重要；StackOverflow相信自己是后者之一（我也同意）。@Dave Sherohman会话劫持并没有伤害到用户，而是用户受到了威胁。个人而言，我尽量遵守OWASP前10名，并且我一直强制使用https。#3违反了OWASP。我应该给你一个-1分。@Rook，我从来没说过它会符合OWASP。我确实说过HTTP允许人们拦截和操纵会话数据。是的，我不认为你把人们引入歧途。该链接是指向imperialviolet.org的，而不是像我在“谷歌”中所预期的那样指向谷歌，并且该链接已断开。@Stephen P，是的，不幸的是，该链接目前已断开。如果你用谷歌搜索链接，你应该能够在缓存中找到文章。虽然确实很难证实，但他们谈论“他们在谷歌的工作”。文章的开头是“（这是我上周四演讲的总结，这是我、纳贡德拉·莫达杜古和万德昌的合著。），见