URL 路径元素中的标识符是否存在任何安全隐患？

Question

我正在使用Devise 实现一个Rails 应用程序，以完成大部分用户身份验证工作。我注意到的一件事是，在为安全敏感任务传递标识符时，它们总是使用查询字符串参数完成。

例如，发送给用户的密码重置电子邮件中包含的 URL 可能如下所示：

http://example.com/users/password/edit?reset_password_token=_aPKoNpLHm7HYs_o4Qex

Devise 根据reset_password_token 查找用户，并在用户重置表单时更改密码。

我刚刚实现了一个 Devise 未处理的类似功能。在每封电子邮件中，我都包含一个退订链接。控制器基于唯一令牌查找用户并将其取消订阅标志设置为 true，即使用户未登录。

但是，我生成的 URL 如下所示：

http://example.com/subscription/3e7eb22a268b62d5/edit

这基本上与 Devise 所做的相同。不同之处在于我将令牌包含在 URL 路径本身而不是查询字符串中。

在我看来，这更像是 RESTful，因为它指向用户随后更新的特定资源（相关订阅）（通过将表单发布到 PUT http://example.com/subscription/3e7eb22a268b62d5）。除了这个好处之外，我认为这两种方法之间没有任何区别。

在 RESTful URL 上使用查询字符串参数有什么原因吗？

Answer 1

是否有什么原因我缺少使用查询字符串参数 通过 RESTful URL？

不是真的。 user a query parameter 和 not 之间唯一真正的区别是一些中间系统可能不会缓存带有查询参数的 URI，因此在这种情况下，在基本 URI 中嵌入标识符是一种解决方法。

也就是说，该论点与您的用例几乎无关。

在高层次上，REST 根本不关心，因为它将 URI 视为一个整体（并且查询参数是 URI 的一部分）。因此，它对此事没有任何建议。两个 URI 都唯一地“命名资源”，因此 REST 很高兴。

习惯上，在 BASE URI 中嵌入 id 非常流行，它可能与边缘情况缓存场景相关，因此，这是唯一真正的粉丝为该表单而不是查询参数挥舞标志。

在外观上，许多人更喜欢嵌入式风格。

我会让你权衡这些考虑因素。

Answer 2

在 URL 中传递令牌在 RESTful 服务中并不是很好。更好的方法是在请求内容中发送它。也就是说，这个令牌是一次性的，与身份验证没有真正的关系，所以它可能不那么烦人......而且我猜这个功能需要通过链接（在电子邮件中）而不是表单来访问提交，这就是为什么使用这样的 URL 参数。

否则，在资源路径 (http://example.com/subscription/3e7eb22a268b62d5/edit) 中诚实地使用操作 (元素 edit) 名称并不是真正的 RESTful ;-) 事实上，操作是由使用的方法本身描述的。对于 POST 方法，如果您想支持多个操作，我们最终还可以使用附加提示。

关于PUT 方法的使用，当您想要更新资源的完整表示时应该使用它。就您而言，我认为您更倾向于使用 POST 方法，因为您想使用重置密码令牌对订阅执行操作（重置订阅密码）。这是我在您的案例中看到的请求：

POST http://example.com/subscription/3e7eb22a268b62d5
{
    "reset_password_token": "_aPKoNpLHm7HYs_o4Qex"
}

我为您提供两个链接，可以帮助您设计您的请求：

• How to Update a REST Resource Collection
• https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/。有点离题，但在相同的上下文中（身份验证令牌、刷新令牌......）

根据 Craig Walker 的评论进行了编辑。

希望对你有帮助 蒂埃里