REST身份验证方案的安全性

Question

背景：

我正在为REST Web服务设计身份验证方案。这并不是“真正”需要安全的（它更多是一个个人项目），但我想使其与练习/学习经验一样安全。我不想使用SSL，因为我不想麻烦，而且在大多数情况下也不需要设置它的开销。

这些SO问题对于我入门特别有用：

RESTful身份验证

保护REST API / Web服务的最佳做法

最佳SOAP / REST / RPC Web API的示例？你为什么喜欢他们？那他们怎么了？

我正在考虑使用Amazon S3身份验证的简化版本（我喜欢OAuth，但对于我的需求而言似乎太复杂了）。我在请求中添加了服务器提供的随机生成的随机数，以防止重放攻击。

要解决这个问题：

S3和OAuth都依赖于对请求URL以及一些选定的标头进行签名。他们都没有在 POST或PUT请求的请求主体上签名。这难道不容易受到中间人攻击，这种中间人攻击会保留url和标头并用攻击者想要的任何数据替换请求正文？

似乎我可以通过在已签名的字符串中包含请求正文的哈希值来预防这种情况。这样安全吗？

Answer 1

先前的答案仅在数据传输的上下文中提到了SSL，实际上并未涵盖身份验证。您真的在问有关安全认证REST API客户端的问题。除非您使用TLS客户端身份验证，否则单独使用SSL 并不是REST API可行的身份验证机制。没有客户端身份验证的SSL仅对服务器进行身份验证，这与大多数REST API无关，因为您确实要对客户端进行身份验证。如果您不使用TLS客户端身份验证，则需要使用基于摘要的身份验证方案（例如Amazon Web Service的自定义方案）或OAuth 1.0a甚至HTTP Basic身份验证（但仅通过SSL）。这些方案验证请求是由预期的人发送的。TLS（SSL）（无客户端身份验证）可确保通过网络发送的数据保持不受干扰。它们是分开的，但又是互补的。对于那些感兴趣的人，我扩展了一个关于HTTP身份验证方案及其工作原理的SO问题。

Answer 2

REST意味着使用Web标准，而Web上“安全”传输的标准是SSL。其他任何事情都会变得很时髦，并且需要为客户端进行额外的部署工作，这将必须具有可用的加密库。原则上，一旦您提交SSL，实际上就不需要花哨的时间了。您可以再次使用Web标准并使用HTTP Basic auth（随每个请求一起发送的用户名和秘密令牌），因为它比精心设计的签名协议要简单得多，并且在安全连接的情况下仍然有效。您只需要确保密码永远不会覆盖纯文本即可。因此，如果曾经通过纯文本连接收到密码，则您甚至可能会禁用密码并向开发人员发送邮件。您还应该确保凭据在收到后不会记录在任何地方，就像您不会记录常规密码一样。HTTP摘要是一种更安全的方法，因为它可以防止传递秘密令牌。而是服务器可以在另一端验证的哈希值。如果您已采取上述预防措施，对于不太敏感的应用程序可能会显得过高。毕竟，用户的密码已经在他们登录时以纯文本格式传输（除非您在浏览器中进行了一些精美的JavaScript加密），并且同样在每次请求时都存储了他们的cookie。请注意，使用API，客户端最好传递令牌-随机生成的字符串-而不是开发人员使用其登录网站的密码。因此，开发人员应该能够登录到您的站点并生成可用于API验证的新令牌。使用令牌的主要原因是，如果令牌被泄露，可以将其替换，而如果密码被泄露，则所有者可以登录到开发者的帐户，并对其进行任何操作。令牌的另一个优点是您可以向同一开发人员发行多个令牌。也许是因为他们拥有多个应用程序，或者是因为他们想要具有不同访问级别的令牌。（已更新，以涵盖仅使用SSL进行连接的含义。）