无会话设计是否可行?

时间:2010-10-26 17:49:27

标签: http session authentication

只是为我即将建立的Web应用程序集思广益。

Web的基石之一是会话处理:让用户登录,发送带有魔术二进制编码的小精灵粉尘的cookie,然后盲目地信任用户。

我只是想知道完全消除通常使用它的网络应用程序的'传统'会话是否可行,例如:在线商店。

这个想法是让一个“服务器端会话”不使用SessionID或任何东西,而是使用用户名。所以每个用户只有1个会话,而不是更多。这将允许像持久购物车这样的东西工作。

身份验证的处理方式类似于Web服务的工作方式:在每个页面视图上预期HTTP摘要身份验证。

忽略匿名访问者必须以不同方式处理的事实,您认为这种方法是否可行?或者,从长远来看,持续认证的额外流量/负载是否会成为一种交易?

5 个答案:

答案 0 :(得分:9)

首先,我们根本不使用会话。

我们发现利用会话使代码复杂化而没有任何好处。甚至考虑使用会话状态只有两个原因。第一个是减少sql server的流量。但是,对于负载均衡的Web服务器等,会话必须存储在sql server中......哪种方式消除了它的第一点。但它更糟糕,因为必须在每个页面加载时检索,反序列化,序列化和存储会话。

第二个原因是不要让浏览器在每个请求上将用户ID传递回应用程序。但是,“会话劫持”是一个相当容易实现的技巧,很少被考虑在内。

因此,我们使用高度加密的cookie,其中包含不可猜测的值,用于指明用户的确切位置。我们将这与不断变化的,不可猜测的请求ID相结合,消除了会话状态(并且它是不必要的开销),同时提高了安全性。

Cookie可以被盗吗?当然,但它的生命非常有限,即两次回发之间的时间量。这意味着它会被发现很快被妥协。

所以,我不会说会议是网络的“基石”。相反,我会说它们是经常使用不当的拐杖,出于安全和性能原因应该避免使用。

所有这一切都说明,你要将这个与用户ID联系起来的唯一方法就是你强迫用户在购物之前登录/创建帐户。除非别无选择,否则没有人会这样做但是要在你的网站上。

哦,不要相信我的话:

4GuysFromRolla.com -> Session variables are evil.
aps.net -> Are session variables still evil?
Scott Hansleman -> Moving Viewstate to Session注意大胆的内容消耗部分,并且能够长时间保持这种状态 Coding Horror -> Your Session has timed out这详细说明了与使用会话相关的一些问题 Wikipedia -> Session Hijacking如果没有指向维基百科的链接,哪些列表是完整的?

答案 1 :(得分:0)

类似REST的实现,例如ASP.NET MVC根本不需要会话状态。

答案 2 :(得分:0)

你应该只使用会话。即使它是你自己的会话实现:例如。 cookie包含用于存储服务器信息的随机密钥。必须使用cookie,或者您必须使用指定密钥的查询参数对网站上的所有链接进行编码 - 不好主意!

然后,我会使用数据库中的人员用户名存储“会话密钥”,或者您要调用的内容。

当用户登录您的网站时,只需恢复之前的“会话”。

其他查询参数选项,这是一个坏主意,您可以通过IP地址跟踪用户。但这又是一个可怕的想法!例如。许多建筑物的互联网IP数量有限,内部计算机数量也是其中的数倍。

没有使用Cookie跟踪用户的好方法。

是的,也许您可​​以使用HTTP身份验证,但为什么要这么麻烦?您只是要介绍新问题并对UI进行限制。

答案 3 :(得分:0)

这实际上几乎是传统会话的作用 - 提供一个独特的标识符来区分浏览器“会话”,你所做的只是将它绑定到用户名而不是随机变量。

我会说你要非常小心你如何生成你的令牌,如果它是可重现的,你可以通过生成别人会话并将其插入cookie来轻松地完成会话固定攻击的目标。这就是会话通常是随机唯一值的原因。

答案 4 :(得分:0)

  

这个想法是让一个“服务器端会话”不使用SessionID或任何东西,而是使用用户名。所以每个用户只有1个会话,而不是更多。这将允许像持久购物车这样的东西工作。

这只是一个会话,但是使用用户名作为会话标识符 - 这将导致各种各样的问题 - 即使你加密它也可以重放攻击。您无法更改每个请求的加密,因为当用户打开第二个窗口或按下后退按钮时,这会中断。

您不能依赖客户端地址 - 多个用户可以共享NAT地址,同一个用户可以从负载均衡代理群集后面访问您的站点。

  

像持久的购物车

...意味着您拥有客户的服务器端数据 - 因为这些数据的大小会有所不同,您无法将其存储在URL或cookie中。

  

期望在每个页面视图上进行HTTP摘要身份验证。

这预先假定您为每个用户创建帐户,并且您不关心不同客户端使用的相同用户ID的影响。我不认为与传统会话相比,这需要更多的处理 - ,但它仍然是基于网络的会话管理,与传统方法相比,存在一系列不同的问题和漏洞。