Web 应用中愚蠢但常见的安全漏洞

图片来自https://www.irasutoya.com/

我记不清见过多少次这种安全漏洞了。我们设计 REST API 时，通常会在 URL 中添加一些 ID。例如，我们有一个返回用户个人资料的 REST API。

GET /users/1234

这个设计本身没有问题。问题在于人们忘记了将 URL 中的 ID 与 Cookie 或 JWT 中的 ID 进行比对。这意味着即使我以 user 身份登录1234，也能获取 user 的个人资料7890。

还有一种情况是 URL 中有多个 ID。就像一个返回交易详情的 REST API。

GET /users/1234/transactions/123-456-789

仅检查用户ID是不够的。我可以做类似的事情。

GET /users/1234/transactions/987-654-321

987-654-321是交易 ID，不属于用户1234。我们必须检查该项目的所有权或访问权限。

如果我们允许某些用户（例如员工、管理员）访问其他用户的信息，情况可能会变得更加复杂。不过我不想在这里讨论这个问题。

我听到有人争论说，用户无法通过前端访问包含其他用户 ID 的 URL ，所以不检查是安全的。当然，我们都知道一个简单的 curl 命令就可以做到这一点。

从前端检查任何内容

为了更具防御性，我们可以简单地不在 URL 中放置用户 ID，而是让后端从 cookie 中获取 ID。

GET /users

但对于物品所有权的情况，我们不能使用这个技巧。

当然，如果你想应用负载平衡或基于URL的分析，这种设计也不适合您。

你可能会觉得这个漏洞真的很愚蠢。我也是这么认为的。但我们也可以从另一个角度看待这个问题。

我们的系统通常包含多个层级。通常情况下，Web 层负责处理来自互联网的流量，而服务层则负责处理业务逻辑并与数据库交互。

图片由https://excalidraw.com/创建

那么应该由谁来检查权限？Web层？还是服务层？没有标准答案。

审查设计也很重要，因为您可能从一个团队开始到多个团队，或者系统设计发生变化。