security - 如何进行无状态(无 session )和无 cookie 身份验证？

Question

Bob 使用 Web 应用程序来实现某些目标。并且:

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

一些重要说明:

• 我们确实有传输安全(HTTPS及其最好的 friend )；
• 在幕后，网络应用程序代表当前用户将许多操作委托(delegate)给外部服务(这些系统确实将 Bob 视为其用户之一) -这意味着我们必须向他们转发 Bob 的凭据。

现在，我们如何(针对每个请求)验证 Bob 的身份？ 哪种方法是实现这样的事情的合理方法？

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

对于前面描述的任何想法，您是否想到过任何网络/安全问题？例如，

• 超时 - 我们可能会保留一个时间戳以及凭证(时间戳 = Bob 输入其凭证的时间)。例如。当NOW - 时间戳>阈值时，我们可能会拒绝该请求。
• 跨站点脚本保护 - 不应该有任何不同，对吧？

非常感谢您花时间阅读本文:)

Answer 1

啊，我喜欢这些问题 - 维持一个没有 session 的 session 。

在申请评估期间，我已经看到了多种方法来做到这一点。其中一种流行的方法是您提到的打网球方式 - 在每个请求中发送用户名和密码以对用户进行身份验证。在我看来，这是不安全的，特别是如果应用程序不是单页的话。它也是不可扩展的，特别是如果您想在将来除了身份验证之外还向您的应用程序添加授权(尽管我猜您也可以构建基于登录的东西)

一种流行但不是完全无状态的机制(假设您有 JavaScript 执行)是将 session cookie 嵌入 JavaScript 中。我内心的安全人员对此感到尖叫，但它实际上可以工作 - 每个请求都有一个 X-Authentication-Token header 或类似的东西，然后你将其映射到数据库，文件存储在后端的内存等来验证用户。该 token 可以有您指定的任何时间的超时，如果超时，用户必须重新登录。它具有相当高的可扩展性 - 如果将其存储在数据库中，执行一条 SQL 语句，并且使用正确的索引，则即使有多​​个并发用户，执行它也应该花费很少的时间。不过，这里的负载测试肯定会有帮助。如果我正确地阅读了问题，这将是您的加密 token 机制 - 不过，我强烈建议您使用 32 个字符的加密随机 token ，而不是使用用户名 + 密码 + 任何其他内容的组合 - 这样，它就保持不变不可预测，但您仍然可以将其与用户 ID 或类似的东西关联起来。

无论您最终使用哪一种，请确保它安全地发送给您。 HTTPS 可以通过网络保护您，但如果您通过 URL 泄漏 session token (或更糟糕的是通过 URL 泄漏凭据)，它就无法保护您。我建议使用 header ，或者如果这不可行，则每次都通过 POST 请求发送 token (这意味着用户浏览器上有一个隐藏的表单字段。)后一种使用 POST 请求的方法应该使用 CSRF 防御，只需以防万一，尽管我怀疑使用 token 本身可能是某种 CSRF 防御。

最后但并非最不重要的一点是，确保后端有某种机制来清除过期的 token 。这在过去一直是许多应用程序的祸根 - 快速增长的身份验证 token 数据库似乎永远不会消失。如果您需要支持多个用户登录，请确保限制数量，或者对每个 token 设置较短的时间限制。正如我之前所说，负载测试可能是这个问题的答案。

我能想到的还有一些其他安全问题，但它们太广泛了，无法在现阶段解决 - 如果您牢记所有使用(和滥用)情况，您应该能够公平地处理该系统的良好实现。