REST API安全基础知识

安全不是事后的想法。它必须是任何开发项目和REST API的组成部分。有多种方法可以保护RESTful API，例如基本身份验证，OAuth等。但有一件事是确保RESTful API应该是无状态的 - 因此请求身份验证/授权不应该依赖于cookie或会话。相反，每个API请求都应附带一些排序身份验证凭据，必须在服务器上为每个请求验证。

REST安全设计原则

论文“信息的保护计算机系统”，由杰罗姆Saltzer和迈克尔·施罗德，提出8个的设计原则在计算机系统中保护信息，如下面的章节中描述：

googletag.cmd.push(function() { googletag.display('waldo-tag-4084'); });

  1. 最小权限：实体应该只具有所需的权限集来执行授权的操作，而不再执行。可以根据需要添加权限，并在不再使用时撤消。
  2. 失败保护默认值：用户对系统中任何资源的默认访问级别应被“拒绝”，除非他们已明确授予“许可”。
  3. 机制经济：设计应尽可能简单。所有组件接口和它们之间的交互应该足够简单易懂。
  4. 完全中介：系统应验证其所有资源的访问权限，以确保它们被允许且不应依赖缓存的权限矩阵。如果正在撤消对给定资源的访问级别，但未在权限矩阵中反映，则会违反安全性。
  5. 开放式设计：该原则强调了以开放的方式构建系统的重要性 - 没有秘密的机密算法。
  6. 权限分离：授予实体权限不应完全基于单一条件，基于资源类型的条件组合更好。
  7. 最不常见的机制：它涉及在不同组件之间共享状态的风险。如果可以破坏共享状态，则可以破坏依赖于它的所有其他组件。
  8. 心理可接受性：它指出安全机制不应使资源更难以访问，而不是安全机制不存在。简而言之，安全性不应该使用户体验变得更糟。

保护REST API的最佳实践

下面给出的点可以作为设计REST API安全机制的核对表。

把事情简单化

保护API /系统 - 它需要多么安全。每当你“不必要地”使解决方案变得更加复杂时，你也可能会留下一个漏洞。

始终使用HTTPS

通过始终使用SSL，可以将身份验证凭据简化为随机生成的访问令牌，该令牌在HTTP Basic Auth的用户名字段中提供。它使用起来相对简单，您可以免费获得许多安全功能。

如果使用HTTP 2来提高性能 - 您甚至可以通过单个连接发送多个请求，这样就可以避免以后的请求产生完整的TCP和SSL握手开销。

使用密码哈希

必须始终对密码进行哈希处理以保护系统（或将损坏降至最低），即使在某些黑客攻击中它受到损害。有许多这样的散列算法可以证明对密码安全性非常有效，例如MD5，SHA，PBKDF2，bcrypt和scrypt算法。

永远不要公开URL的信息

用户名，密码，会话令牌和API密钥不应出现在URL中，因为这可以在Web服务器日志中捕获，这使它们很容易被利用。

https://api.domain.com/user-management/users/{id}/someAction?apiKey=abcd123456789 //非常糟糕!!

以上URL公开API密钥所以，永远不要使用这种形式的安全性。

考虑一下OAuth

虽然基本身份验证对于大多数API都足够好，但如果正确实现，它也是安全的 - 但您也可能想要考虑OAuth。OAuth 2.0授权框架允许第三方应用程序通过编排资源所有者和HTTP服务之间的批准交互，或者通过允许第三方应用程序来代表资源所有者获得对HTTP服务的有限访问权限以自己的名义获取访问权限。

考虑在请求中添加时间戳

与其他请求参数一起，您可以在API请求中将请求时间戳添加为HTTP自定义标头。服务器会将当前时间戳与请求时间戳进行比较，并且只有在合理的时间范围内（可能是1-2分钟）才接受请求。

这将阻止那些试图在不更改此时间戳的情况下强行执行系统的人进行非常基本的重播攻击。

输入参数验证

在到达应用程序逻辑之前，在第一步验证请求参数。如果验证失败，请进行强有力的验证检查并立即拒绝请求。在API响应中，发送相关的错误消息和正确输入格式的示例以改善用户体验。