我可以/应该为只读 API 做哪些简单的安全考虑?

信息安全 Web应用程序 tls 红宝石
2021-08-26 02:47:58

现在我正在设置一个 API,在客户端使用来设置一个目录站点。我想知道为了防止人们获得对数据的写访问权限,我需要采取哪些额外步骤。

一些注意事项:

  • API / 数据库没有私人信息。所有信息都可用,而且都不是 PII 等。如果有人阅读了所有数据,这对我来说不是问题。
  • 目前,该 API 是一个 Sinatra 应用程序,它确实具有写入方法,因此我可以添加受 HTTP Auth 保护的数据。
  • 它将托管在 Heroku 上并仅通过 HTTPS 提供服务。
  • 数据不会经常变化。
  • 数据将定期备份,因此即使是破坏性的闯入也不会是世界上最糟糕的事情。

我的问题:

  • 在这种情况下,我应该阅读有关安全方面的特定领域吗?
  • 将 API 写入方法(和管理员)移动到完全不同的应用程序,然后简单地同步数据库来处理大多数安全问题吗?
  • HTTP Auth 使用长用户名和密码是否足够安全,或者是否有比 HTTP Auth 更好的方法在管理员中授权自己?

(注意:我已经查找了相关问题并发现了这一点:如果通过 HTTPS 完成 BASIC-Auth 安全吗?但目前还不清楚是否有更好的选择或方法不会带来更多的安全隐患)

  • 还有其他提示或想法吗?

我目前有点脱离我的元素,我想把这个项目付诸实施,而不是拖延太久。我确信没有什么可以替代适当的应用程序安全培训,但我希望由于数据的公开性,我可以忽略大多数安全情况,然后花更多时间了解它们。

干杯,安德斯

3个回答

本质上,您只需要浏览标准的OWASP Top 10并专注于正确获取访问控制内容。

就身份验证而言,出于多种原因应避免使用基本身份验证。它很丑陋,不安全,并且没有得到普遍支持。标准模型是为用户提供一个随机生成的 API 密钥,该密钥与他们的正常登录凭据分开。这允许进行合理的身份验证,而不会有凭据被盗的风险。无论如何,我仍然建议在整个 API 中使用 HTTPS,看起来您已经在这样做了。

拆分 API 确实是最好的选择,因为公共站点只需要只读,没有理由让写入 API 存在于其上。这也将使您能够更轻松地实施其他限制,例如限制可以访问管理站点的 IP 地址。

如果做不到这一点,使用作为多项式提到的 API 密钥或访问 API 的会话令牌是下一个最佳选择,因为它允许您调用 API 而无需在每个请求中发送凭据,这可能更安全。

但是,听起来您对应用程序的安全顾虑相当少,因此我想说具有足够强密码和 HTTPS 的基本身份验证可能是一个完全可以接受的初始实现。鉴于您是唯一一个会写信给该网站的人,我不知道我是否同意多项式对丑陋或缺乏普遍支持的担忧。

您引用的 AviD 的帖子中介绍了有关基本身份验证的不安全问题,如果您想缓解这些问题,您可以实现像Warden这样的基于 Sinatra 的身份验证模块,而不是使用基本身份验证。

这个问题太宽泛了,无法回答。老实说,这只是感觉你在要求某人为你做你的工作。话虽如此,我会尽量以最好的方式回答你。您需要做的第一件事是处理OWASP Top 10 List密切关注注入漏洞和会话管理。

之后,确保 API 的公共端使用的数据库用户对数据库具有只读访问权限。

至于HTTP 基本身份验证,只要您使用 HTTPS,我认为它不会在您的情况下带来巨大的安全风险。由于只有管理员需要进行身份验证,因此无需使用 API 密钥使过程过于复杂。