仅使用 HTTPS 是否足以保护 API RESTful Web 应用程序？

Question

我正在研究一个新的 Web 应用程序，我想使用 HATEOAS、RESTful 原则开发它。我正在研究身份验证方案和网络应用程序身份验证信息（通过浏览器，而不是机器对机器），似乎有点缺乏。

在建立 HTTPS 会话和初始登录后，似乎不需要传递令牌、cookie、HMAC、nonce 等。基本身份验证或 HMAC、OAuth 等似乎也不重要：HTTPS 会话是安全的。

我可能遗漏了一些东西。以下是我想象的解决方案的工作方式：-

1. 用户导航到 Web 应用程序的登录页面 (HTTPS://acme.com/login)
2. 用户指定用户名和密码
3. Web 服务验证用户名和密码：允许访问授权资源

为了让服务器在后续请求中识别经过身份验证的用户，它可以：-

1. 将明文用户名作为标头或 cookie 传递 - 这是 RESTful，IMO
2. 使用 SSL 会话 ID（如果框架可用），查找用户。这不像 RESTful 那样需要存储会话 ID

我认为没有理由使用 HTTPS 以外的任何东西。我错过了什么，有哪些漏洞或缺少的功能？

谢谢！

Answer 1

您必须在此处定义安全性。 SSL 相当安全（尽管 OpenSSL/Heartbleed 最近出现了问题）。

但是，我看到您使用的是用户名和密码/登录名，为什么不将 HTTP Basic 和 HTTPS 结合使用？大多数框架都支持基本身份验证，所以。每次拨打电话时只需对用户进行身份验证。这是通过身份验证实现 RESTFul 的唯一方法，因为您希望成为无状态的。

Answer 2

HTTP 基本身份验证（即用户名和密码）+ HTTPS 通常被认为对于大多数 REST API 来说足够安全，尤其是对于内部使用而言。但是，如果没有唯一的 nonce（或事务 ID），您很容易受到重放攻击。

例如，假设攻击者能够记录一个真正的 PUT 请求以在您的数据库中创建一些新记录。然后，他们可以循环重播该消息，通过填充您的数据库表来对您的 API 发起 DoS 攻击。尽管消息是通过 SSL 加密的，但它仍然包含有效的凭据，因此来自攻击者的每个重放请求都将被您的 API 尽职尽责地解密并成功验证。

HTTP Digest Authentication 包含一个随机数，该随机数会针对每个请求进行更改，因此被认为是更安全的选项。