RESTful 安全：堵住漏洞！

TL;DR：不要通过 HTTP 错误代码泄露信息。

这里有一个潜在的漏洞，可能不是很严重，但很容易被忽视。假设我们受雇重新设计一家本地银行的网站。作为资深程序员，我们决定创建一个美观的 RESTful API。

我们的 API 操作之一如下：

GET /api/accounts/{acctId}

当然，只有当 ID 对应的账户acctID存在且请求包含该账户所属客户的有效凭证时，此操作才会成功。如果其中一个条件不成立，我们将返回相应的 HTTP 错误代码。

错误代码应该是什么？我们知道 RESTful API 会根据具体情况返回最合适的状态码。因此，当帐户不存在时返回 404 似乎比较合理，而当帐户存在但用户未经身份验证或不是帐户所有者时则返回 401。

但这可能是一个坏主意，因为未经身份验证的用户现在可以做这样的事情：

$ for i in `seq 300 305`; do curl -sI https://exammple.com/api/accounts/${i} | head -n 1; done
HTTP/1.1 404 Not Found
HTTP/1.1 401 Unauthorized
HTTP/1.1 401 Unauthorized
HTTP/1.1 404 Not Found
HTTP/1.1 401 Unauthorized
HTTP/1.1 404 Not Found

这个未经身份验证的用户现在已经了解了一些信息：没有 ID 为 300、303 和 305 的帐户，但有 ID 为 301、302 和 304 的帐户。当然，使用更广泛的 ID 运行此命令将会显示更多信息。

这有多糟糕？这取决于很多其他因素；目前，我们最多只能说情况不算太糟。但这仍然可以用于了解其他信息——例如，新账户的创建速度，这可能会引起竞争对手的兴趣。

重点在于，这个 API 会将信息泄露给那些没有正当理由获取这些信息的用户。这个问题很容易修复：即使账户确实存在，我们也应该返回 404 错误。

结论

虽然我们关注的是显而易见的安全问题——保持账户余额的秘密，防止未经授权的交易——但很容易忽视我们的系统行为如何泄露敏感信息。

攻击者的目标是通过观察系统行为来获取有关系统状态的信息。因此，我们的工作是确保系统无论处于何种状态，其行为（从攻击者的角度来看）都保持一致。请记住：未经身份验证的用户并非唯一的潜在攻击者。即使是已登录的用户，在访问非其所有帐户的请求时也应该会收到 404 错误响应。