简单、安全的 PHP API 设计

信息安全 验证 网络服务 随机的 令牌 api
2021-09-02 00:41:50

我正在尝试设计一个安全的 RESTful API Web 服务,其中的移动部件尽可能少。我有一些问题,想确保我的设计是安全的。

对于数据传输的安全级别,我打算使用 SSL/TLS 来防止拦截、MITM、重放攻击等。

剩下的是访问控制。

我不想与 OAuth 抗争。原因是,我不想依赖第三方,并且将本地服务器设置为“身份验证器”(或任何 OAuth 所称的)是不可行的。

所以我打算依赖一个随机令牌。使用 CSPRNG 库(例如,$token = random_bytes(32)在 PHP 中),我计划分配每个用户名/密码 a $token,并使用密码存储功能(例如,PBKDF2 或 bcrypt)将其存储在数据库中。用户也可以通过 SSL/TLS 检索令牌。

然后,在每个请求中,用户将连同他们的 JSON 数据一起提交令牌。如果他们传递的令牌存在于数据库中,则处理 API 调用。

这给我留下了很多问题:

  • 令牌能否保持一致(没有撤销或手动刷新),还是需要经常“刷新”令牌?如果是这样,处理它的可行方法是什么?强制用户登录网页以访问新令牌似乎违背了 API 的目的。似乎表明它充其量是一个有争议的观点。
  • 将令牌放入 HTTP 标头(例如Authorization: Token SOMERANDOMVALUE)与仅将其填充在 JSON 请求的正文中有什么优势?无论哪种方式,除非身份验证成功,否则我不会对请求执行任何操作。无论如何,我打算把它放在标题中,但我只是好奇。

此外,如果有人有任何值得信赖的资源来了解有关构建安全 API 的更多信息,我真的很想阅读它们。

1个回答

令牌能否保持一致(没有撤销或手动刷新),还是需要经常“刷新”令牌?如果是这样,处理它的可行方法是什么?

即使您不想实现 OAuth,我还是建议您看看在OAuth 中令牌处理是如何完成的(第 1.5 和 1.5 段)使用刷新令牌,如果不记名令牌遭到破坏,您可以减少暴露窗口,同时避免要求用户重复提供他们的凭据。

将令牌放入 HTTP 标头(例如,授权:令牌 SOMERANDOMVALUE)与仅将其填充在 JSON 请求的正文中有什么优势?

AFAIK 已完成,因为此标头字段用于此目的。在实践中,它在很大程度上取决于用例。由于Authorization某些浏览器会自动发送标头可能会引入 CSRF 漏洞,因此如果您不想实现 CSRF 令牌,则可能不希望这样做。因此,将身份验证信息添加到正文或自定义标头字段是完全可以的。

查看OWASP 的 REST 安全备忘单,了解有关安全 API 设计的更多提示。实际上整个网站都很有趣——这是一个很好的起点,可以更好地理解信息安全。