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

Question

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

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

我可能错过了一些东西。以下是我想象我的解决方案的工作原理： -

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

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

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

我认为没有理由使用除HTTPS之外的任何其他内容。我缺少什么，漏洞或功能缺失？

谢谢！

Answer 1

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

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

HTTP摘要式身份验证包括针对每个请求更改的随机数，因此被视为更安全的选项。

Answer 2

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

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