限制对 RESTful 资源的访问

Posted 2023-02-19

【中文标题】限制对 RESTful 资源的访问

【英文标题】：Restrict access to RESTful Resources

【发布时间】：2011-10-14 11:32:16

【问题描述】：

在为应用程序设计 REST API 时，一些服务应该是公开的，而其他服务最好保持私有（即不可公开访问）。服务应用程序使用 OAuth。

需要考虑哪些措施？

一些想法：

在混淆的 URI 下发布私有资源。 需要特殊的访问密钥。 （只有授权客户知道）。

【参考方案1】：

任何需要保护并仅限于特定受众群体的资源都需要有适当的访问控制（基本上就是您在第 2 点中所说的）。作为指南，请参考 Twitter 等成功服务的 API，您总能找到相关的令牌。

混淆是绝对不能接受的——这只是security through obscurity 并且从根本上是有缺陷的。仔细阅读 OWASP Top 10 的部分内容，failure to restrict URL access。相同的规则适用于任何资源，无论它们是 RESTful 还是其他。

【讨论】：

访问控制应该首先确定，深度安全将是一个难以猜测的 URL。

几乎不值得，而且几乎没有任何意义来代替适当的访问控制：“安全虽然默默无闻是一种薄弱的安全控制”：owasp.org/index.php/Avoid_security_by_obscurity

【参考方案2】：

最具可扩展性的方式是设计 URL，这样中间人就可以轻松知道哪些资源可供所有人使用，哪些资源仅供特定用户使用。

然后代理或 servlet 过滤器或任何适合您当前需求的东西都可以进行授权，阻止所有未经授权的请求。 实际的服务现在可以盲目地信任和服务所有到达它的请求。

关注点分离等等。

例子：

未经身份验证的请求可以到达：

/myapi/public

使用用户名“joe”认证的请求也可以到达：

/myapi/personal/joe

401 未经授权：

/myapi/personal/anything_but_joe 

确保 /myapi/personal/otheruser 和 /myapi/personal/nonexistentuser 返回无法区分的响应。

【讨论】：

是的，在这种情况下，访问控制将由 OAuth 令牌控制。只接受一组已知密钥。否则我认为 404 会满足。

我认为这是不对的。 API 应该围绕 HATEOAS 设计，这意味着您的根 URI 的响应（它们应该是“书签”的唯一 URI）根本不提供指向给定用户无权访问的 URI 的链接。如果您以管理员身份登录，则 API 返回的链接集与以特定用户身份登录的人完全不同，如果您未经身份验证，则只能看到公共 URI。 IMO 那些 URI 应该只描述资源层次结构，而不是可见性。有权访问该特定资源或提要的任何人都应该具有相同的 URI。

“应该”我只是指如果您想创建一个 RESTful 服务并获得仅依赖链接关系而不是任何 URI 而不是书签“根”URI 的可发现性/稳健性优势。如果你不做 HATEOAS，你就不是在做 REST - 只是一个 HTTP API - 如果你不需要这些好处并且不想做那个工作，那很好:)

我描述的 URL 布局只是服务器端的实现细节，不会影响 HATEOAS。因此，尽管我认为您是对的，但我看不出它与我所写的内容有何矛盾:-) 除非客户端经过硬编码以在没有发现的情况下利用布局，这与我的观点无关。