如何进行无状态(无会话)和无cookie的身份验证?


107

鲍勃使用Web应用程序来实现目标。和:

  • 他的浏览器处于节食状态,因此不支持cookie
  • Web应用程序是一种流行的应用程序,它在给定的时刻可以与许多用户打交道-它必须很好地扩展。只要保持会话会限制同时连接的数量,并且当然会带来不可忽略的性能损失,我们可能希望拥有一个无会话系统:)

一些重要的注意事项:

  • 我们确实具有传输安全性HTTPS及其最好的朋友);
  • 在幕后,Web应用程序代表当前用户(这些系统确实将Bob识别为用户之一)将很多操作委托给外部服务 -这意味着我们必须向他们转发Bob的凭据

现在,我们如何对Bob进行身份验证(针对每个请求)?哪种方法可以实现这种情况?

  • 通过HTML表单隐藏字段使用凭据打网球 ... 包含凭据(用户名和密码),两个球拍分别是浏览器和Web应用程序。换句话说,我们可以通过表单字段而不是通过cookie来回传输数据。在每个Web请求中,浏览器都会发布凭据。但是,对于单页应用程序,这看起来像是在橡胶墙上打壁球,而不是打网球,因为包含凭据的Web表单可能会在整个页面生命周期中保持有效 (并且服务器将配置为不提供凭据)。
  • 将用户名和密码存储在页面的上下文中-JavaScript变量等。此处需要单页,恕我直言。
  • 基于加密令牌的身份验证。在这种情况下,登录操作将导致生成加密的安全令牌(用户名+密码+其他内容)。该令牌将被发还给客户端,并且即将到来的请求将带有令牌。这有意义吗?我们已经有了HTTPS ...
  • 其他...
  • 不得已:不要这样做,将凭据存储在会话中!会议很好。有或没有cookie。

关于上述任何想法,您是否会想到任何Web /安全性问题?例如,

  • 超时 -我们可以保留一个timestamp以及凭据(时间戳= Bob输入凭据的时间)。例如,当NOW-timestamp> threshold时,我们可能会拒绝该请求。
  • 跨站点脚本保护-不应有任何不同,对吗?

非常感谢您抽出宝贵的时间阅读本文:)


1
您可以将令牌附加到每个URL。ASP.NET具有(传统)模式来执行此操作。这证明它可以工作。
usr

1
大家都去哪了?:)
turdus-merula

2
我认为您对可用的选项有了很好的了解。相信您的推理并自行决定。
usr

是否可以选择像flash的silverlight插件?
Giu 2014年

@usr不确定这是否是一个好主意,好像黑客进入您的网络服务器日志可以窃取您的令牌并登录您的系统。
GibboK '16

Answers:


74

啊,我喜欢这些问题-维持一个没有会议的会议。

在应用程序评估期间,我已经看到了多种方法来执行此操作。一种流行的方式是您提到的打网球方式-在每个请求中发送用户名和密码以验证用户身份。我认为这是不安全的,尤其是在应用程序不是单页的情况下。它也不具有可扩展性,尤其是如果您将来希望在身份验证之外向应用程序添加授权时(尽管我想您也可以基于登录信息来构建内容)

一种流行的(尽管不是完全无状态的)机制(假设您已执行JavaScript)是将会话cookie嵌入到JavaScript中。我内心的安全人员对此大喊大叫,但实际上可以正常工作-每个请求都有一个X-Authentication-Token标头之类的东西,然后将其映射到数据库,后端文件在内存中的存储等,以验证用户。此令牌可以具有您指定的任何时间的超时,如果超时,则用户必须再次登录。它具有相当的可扩展性-如果将其存储在数据库中,执行一条SQL语句并具有正确的索引,则即使有多​​个同时用户,它也将花费很少的时间来执行。虽然这里的负载测试肯定会有所帮助。如果我正确阅读了该问题,那将是您的加密令牌机制-尽管我强烈建议您使用说32个字符的加密随机令牌,而不是使用用户名+密码+其他任何方式的组合-这样,它仍然存在不可预测,但您仍可以将其与用户ID或类似的东西相关联。

无论您最终使用哪个,请确保将其安全发送给您。HTTPS全面保护您的安全,但是如果您通过URL泄漏会话令牌(或更糟糕的是,通过URL泄漏凭据)则无法保护您。我建议您使用标头,或者如果这样做不可行,则每次通过POST请求发送令牌(这意味着用户浏览器中的表单字段为隐藏字段。)使用POST请求的后一种方法应使用CSRF防御,万一,虽然我怀疑使用令牌本身可能是某种CSRF防御。

最后但并非最不重要的一点,请确保后端具有某种机制来清除过期的令牌。过去,这一直是许多应用程序的祸根-迅速增长的身份验证令牌数据库似乎从未消失。如果需要支持多个用户登录,请确保您限制数量或对每个令牌有较短的时间限制。就像我之前说过的,负载测试可能是答案。

我还可以想到其他一些安全问题,但是这些问题太广泛了,无法在此阶段解决-如果您牢记所有使用(和滥用)案例,那么您应该应该能够很好地实现这个系统。


您是否可以执行播放框架的工作并将签名的Cookie发送给用户?然后,对于每个后续请求,是否已将该Cookie发送回服务器?
j将

8
>他的浏览器处于节食状态,因此不支持cookie。
Karthik Rangarajan

4
这些建议中有没有实际上是无状态/无会话的?在您的五个主要段落中(截至2013-12-19版):#1是入门课程,2提出了多余的Web2.0™-Flavored会议,#3只是警告,#4讨论了含义是有状态的,#5是模糊的结局...这是如何被接受的?最好是切向的信息!
JamesTheAwesomeDude18年

1

关于登录选项-我认为通常您也希望为来宾提供会话支持。

因此,如果要强制登录,则加密令牌选项可能不错。无论如何,这对于来宾会话也可能是好的。在另一个方向上,我将在将令牌附加到URL和网球选项之间进行组合。

请注意,仅在URL中发送凭据可能很危险。例如,您可能通过HTTP引用标头或什至只是检查您的流量或监视您的计算机的人员泄漏令牌。

另一件事,即使您可以使用cookie,我也建议您添加随机令牌或随机verifer,以保护自己免受跨站点请求伪造(CSRF)攻击。


3
会话是存储在服务器上的状态。这个问题要求无状态认证。
Kwebble
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.