站点如何安全地支持HTTP(非SSLED)会话?

正如蒂洛所说,但我将进一步解释:)

Web服务器是无状态的!这确实是认证案例的问题。你不能只登录,然后说“从现在开始,这个用户已经登录”-你需要一些方法来确定这次请求新站点的用户是谁。

实现这一点的一种常见方法是实现会话。如果您在登录时通过数据包嗅探网络流量,然后浏览某个站点,您通常会注意到如下情况:

登录:您将把您的用户名和密码传输到服务器。完全未加密!(ssl/https将为您加密此请求,以避免中间人攻击)

回答:您将收到一个随机生成的字符串,其中包含许多奇怪的字符。这些通常存储在cookie中。

只有您有权访问某些站点的请求:您将把随机生成的字符串传输到服务器。服务器将查找这个字符串,并查看它是否与您的会话相关联。这允许服务器识别您的身份,并授予您访问站点的权限。

…现在,HTTP本身并不安全。这意味着您的密码和会话cookie(随机生成的字符串)将完全不加密地传输。如果有人可以访问您的流量(通过特洛伊木马、路由器劫持等),他将能够在您登录时看到您的用户名/密码,如果您不使用HTTPS。这将允许他访问您的网站,直到您更改密码(除非他先更改密码:p)。在其余的请求中,他将能够获取您的会话cookie,这意味着他可以在该cookie生命周期的剩余时间内窃取您的身份(“直到您注销,或者会话在服务器上过期)。

如果你想感觉安全,使用https。实际上,把一个键盘记录器应用到你的电脑中比读取你所有的流量要容易得多。)

(或者正如其他人指出的那样,使用跨站点脚本来读取会话cookie)

它只有在密码不以明文形式传输的情况下才是安全的。在HTTP模式下拦截和滥用Gmail会话cookie是可能的(并且已经完成)。

为了避免会话劫持,您需要保持HTTPS模式(我认为现在Gmail提供了这种模式)。

这只比纯HTTP稍微安全一点——登录名/密码不会以纯文本的形式传输。除此之外,它的工作原理与普通的基于HTTP cookie的会话完全相同(因为它就是这样);因此,所有的会话劫持问题都适用。

这是不可能的,也不安全。这就是为什么我们有“安全饼干”的原因。尽管它很好地抵御被动嗅探攻击,因为用户名/密码不会被公开,但是会话劫持仍然是可能的。

也可以看看这个 SSL Implementation Security FAQ 纸。