使用 REST API 进行正确的会话管理

Posted 2023-03-08

【中文标题】使用 REST API 进行正确的会话管理

【英文标题】：Proper Session Management with REST API

【发布时间】：2018-04-30 01:34:24

【问题描述】：

我已经完成了 RESTful API 的设计，在其中我使用作为参数发送的 API 令牌对每个请求进行身份验证。 现在我想创建一个客户端界面，我想知道管理与每个 浏览器 客户端的会话的正确安全方法是什么。

我考虑过一种流程来保持服务器端无状态：

Web 客户端使用用户名和密码登录 带有用户 API 令牌的服务器响应 客户端将令牌存储为 cookie 客户端将令牌作为每个请求的参数发送，正如 API 服务器所期望的那样

但我觉得这里有些不对劲……这不是太脆弱了吗？ 假设我正在使用 SSL，但仍然， API令牌不能这样被轻易窃取吗？ 它甚至是一种正确的工作方式吗？

【参考方案1】：

将您的令牌存储在 Web 应用程序的 cookie 中，因为 它们提供的额外安全性，以及保护的简单性 使用现代 Web 框架对抗 CSRF。 html5 网络存储是 易受 XSS 攻击，具有较大的攻击面，并且可以影响 成功攻击的所有应用程序用户。

请参考以下链接：

https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

【讨论】：

请注意，虽然答案中提到的链接与 JWT 相关，但也是一个令牌。因此，您可以存储链接中提到的自定义生成的令牌。

JWT 可以防止中间人攻击。它并不真正适用于身份验证。特别是因为正确设置 HTTPS 的 TSL 将提供相同的功能，但速度更快，算法更好。

而且，是的，CSRF 保护是一个不错的好处，但它只是攻击媒介之一。

【参考方案2】：

在适当的 REST 中，您无法进行会话。因为它们往往存储在服务器上。

因此，您需要为每个请求重新识别用户。

您目前拥有的是 OAuth 方法。您发行一个令牌，如果提供该令牌，它将被视为身份证明。如果有人设法窃取了该令牌，则没有简单的方法可以检测到它。至于“如何被盗”，主要载体是 XSS、浏览器扩展和物理访问。你可以缓解 XSS，但对于后两者你真的无能为力。

还有 CSRF 作为向量，正如@Saikrishna Radarapu 提到的那样，但是，如果您将令牌存储在某个地方，那不是 cookie，这不是真正的问题。

所以……可能的选择。

最简单的方法就是为您的身份验证令牌添加过期时间。当令牌过期时，您要求用户重新登录。这样，成功的攻击将导致... emm .. 机会窗口，您可以在执行破坏性操作时通过要求用户重新输入密码来进一步限制。

另一种选择是基于this approach for remember-me cookies 对tokens 进行建模，但这种方法有一个严重的缺点——它在异步环境中表现不佳。您可以通过为每个令牌应用“保险丝”来缓解它 - 在首次使用时将其标记为“易失性”并为其分配 X 秒的“燃烧时间”。随着那些X 秒继续返回相同的“新”令牌，然后将原始令牌标记为“过期”。

我想到的第三个选项是只使用 HTTP Basic Auth 或 Digest Auth，但我从未在实践中真正尝试过。

所以......这是我在这个话题上的两分钱。

【参考方案3】：

请注意，RESTfull API 不需要接口并且是无状态的。 您的问题可以分两种情况考虑： 1：在第一种情况下，您有一个服务器，它只是一个 REST_API 服务器，没有接口，对有效请求有 json 响应，其他服务器（来自不同的 IP）发送他们的请求，所以你不能用会话管理客户端，因为它是一个服务器到服务器的通信，每台服务器都只有一个 IP。所以令牌是您的最佳选择。 2：在第二种情况下，您提供了相同的功能，但您希望在同一服务器中的 REST_API 旁边有一个接口，现在您可以使用会话的接口和其他（其他服务器）使用令牌。 在这两种情况下，最好的方法是使用令牌。您可以使用可签名且更安全的 JWT 令牌。 另请注意，当所有内容都在同一台服务器上时，您可以将会话用于该服务器的自己的界面。