分析 RESTful API 安全性及如何采取保护措施

[vocalman]

本文中讨论了 API 安全性和采用安全措施的重要性，如身份验证，API 密钥，访问控制和输入验证。

API 设计的第一步是撰写接口文档

根据 TechTarget （海外 IT 专业媒体）的定义，RESTful API 是一个应用程序接口，它使用 HTTP 请求来获取 GET，PUT，POST 和 DELETE 等数据。从技术层面上看，RESTful API （也称为 RESTful Web 服务）是一种基于代表性状态转移（ REST ）技术，这是一种通常用于 Web 服务开发的架构风格和通信方法。

但随着 RESTful API 应用范围的爆炸性扩大，安全性越来越成为 API 架构设计中最容易被忽视的部分。

为什么 API 安全性很重要？

在设计和部署 RESTful API 时，有以下三个核心原因可以解释为什么安全性应该是一个很重要的考虑因素。

▼1.数据保护

RESTful API 是一种向外界传输价值的服务方式。因此，保护通过 RESTful 方式提供的数据始终应该是属于高优先级。

▼2.DOS 攻击

如果不采取正确的安全措施，（ DOS ）攻击可以使 RESTful API 进入非功能状态。考虑到很多基础的 RESTful API 是开放给所有人使用的情况，通过这种类似开源的方式有助于它更好推广给市场，让更多人投入使用，但同时意味着如果有人选择对 API 执行 DOS 攻击时，它也可能导致灾难性的结果。

▼3.商业影响

如今有越来多的服务平台，提供着影响衣食住行的各种信息，从飞机航班时刻表到高铁余票查询，甚至只是超市里日常用品，都能给你提供价格、数量、时间等诸多信息，让你足不出户，买到最合心意的商品。

在这样的大趋势下，这种利用 API 数据来获取更多信息，再提供给你的聚合服务平台将会越来越多。于是通过 RESTful API 传输的信息会被频繁调用，而其中的个人信息很容易被泄露。

保障安全采用的措施

以下介绍一些 RESTful API 通用设计中的关键概念。

▼1.会话管理和认证

除了使用 TLS / HTTPS 之外，最重要的 RESTful API 安全级别是以会话管理和身份验证为中心的。在本文讨论中重点将放在 API 密钥，OpenID Connect / OAuth2 / SAML 和会话状态事项上。

▼2.API 密钥

API 密钥的概念是为使用者提供了作为其 HTTP 请求的一部分的唯一字符串（密钥）。虽然不是一个完整的安全解决方案，但与匿名使用相比，使用 API 密钥可以更清楚地了解谁在使用 API。

API 密钥也可用于提供附加服务。例如，对于 RESTfulAPI，附加的服务可以选择使用不同的级别。以一般、高、最高三个等级为例，在“一般”的级别，用户可以自由访问，但只能访问一组有限的数据。假如要访问更多组的数据，那就必须支付费用才能访问“高”的级别，以此类推，不受限制的访问所有的数据则要支付“最高”等级的费用，通过提供不同 API 密钥的方式，提供额外的服务。

使用 API 密钥的最常用的方式是将它们包含在请求头中。

例如，当调用某个小部件的头部时，67A73DD1BD1D90210BA 的 API 设置为 HTTP 头部中的 X-API-KEY 键 /值对：

curl-H “ X-API-键：67A73DD1BD1D90210BA ”

API 密钥的另一个常见用法是将该密钥包含在 URI 中：

https://www.example.com/v1/widgets?api_key= 67a73dde1bdd1d90210ba

但这种方法的问题在于，API 密钥在浏览器历史记录和对应服务器的日志中都会显示出来，意味着向所有有权访问这些数据的人公开唯一密钥。

▼3.OpenID Connect，OAuth2 和 SAML

OpenID Connect，OAuth2 和 SAML 使用 HTTP 协议作为传输，用于安全目的。身份验证提供个人的验证，同时授权执行或撤消访问的任务。

从身份验证角度来看，存在以下选项：

• OpenID Connect：可以利用现有的身份提供商（如 Google 或 Facebook ）获取用于验证用户授权的令牌。
• OAuth2：可以通过授权执行伪认证（如下所述）。
• SAML：使用断言、协议、绑定和配置文件来管理身份验证，包括标识提供者，但不太适合移动应用程序验证。

为提供授权服务，采用以下策略：

• OAuth2：提供安全的委托访问，通过允许第三方身份提供程序颁发令牌来代表用户执行操作。由于 OAuth2 必须了解被委派的用户，因此身份验证是以伪方式实现的（如上所述）。
• SAML：对可信服务执行断言，包括提供授权的令牌。

▼4.会话状态事项

RESTful API 端点应始终保持无状态会话状态，这意味着会话的所有内容都必须保存在客户端。来自客户端的每个请求都必须包含服务器理解请求所必需的所有信息。为了简化流程，包括 API 令牌以及会话令牌，作为每个业务中都需要的一部分。

▼5.访问控制

如上所述，对 RESTful 服务的授权可以将安全性引入到所提供的端点中，以便对那些可以向 API 发出 HTTP 删除请求的人有限制。

在下面的简单 Java 示例中，只有 Admin 和 Manager 角色（即组）的成员可以执行删除所有用户的 DELETE 请求，但是所有用户都可以执行 GET 请求以获取用户列表：

▼6.速率限制

如上所述，API 密钥是判断 RESTful API 的使用者身份级别一种很有用的策略。除了提供等级识别外，使用 API 密钥的另一个好处是能够限制 API 的使用，例子像 Tibco Mashery、MuleSoft 和 Dell Boomi 等 API 管理解决方案允许限制 API 请求，利用 API 密钥实现此功能。因此，试图执行 DoS 攻击（有意或无意）的时候将会达到一个设定的阈值，到达阈值后后续所有的请求都将被拒绝。

▼7.输入验证和 HTTP 返回代码

在保护 RESTful API 时，应始终考虑对输入进行验证。例如，如果用户试图发布与地址相关的 JSON 数据集合，则 RESTful 端点内的服务应验证数据并使用 HTTP 返回代码来反映正确的状态。在下面简化的 Java 示例中，就是调用一个非常基本的 AdvSersService 来验证和保存地址：

在上面的示例中，使用 isValidAddress （）方法验证 newAddress 对象（从 JSON 编组到 Address Java 对象）。如果地址无效，则向用户返回 HTTP 401 （错误请求）代码，文本显示为“提供的地址无效。” 如果认为该地址有效，则 convertAddress （）将执行必要的操作，然后将包含地址内容的 JSON 格式的字符串返回给用户，以及一个 HTTP 201 （创建）返回代码。

结论

保护 RESTful API 的安全应该始终处于 API 设计工作中最先被考虑的部分。如果不保护敏感数据，允许 DOS 攻击以及不考虑使用 RESTful API 的影响，那么即使它只是短暂的影响，相关的风险可能很容易使企业处于不利地位。

授权和身份验证可以为 RESTful API 提供必要的安全性，实现 API 密钥策略可以有效的用最低成本保护 RESTful API 的安全。对输入内容进行验证始终应该是 RESTful API 的一部分，因为无法保证 API 后续是否会进行任何必要的验证，同时返回到客户端的结果应该符合预设中 HTTP 返回代码，而不仅仅只是状态码显示的成功（ 200 ）或者错误（ 404 ）。

除了 API 的安全性需要被保护，时刻掌握 API 运行中的动态也是很重要的事情。EOLINKER 提供完善的 API 监控功能，帮您随时掌握 API 的动态，让您快速对 API 业务进行监控，帮助运维人员精准维护 API，减少企业因 API 服务不可用而导致的服务停止以及经济损失。对 API 管理、监控等方面有兴趣的小伙伴了解下哦！https://www.eolinker.com

你使用过 RESTful API 吗？又对 RESTful API 安全性有什么看法？欢迎在下方留言中与我讨论。

原标题：RESTful API Security

作者：John Vester

原文地址： https://dzone.com/articles/restful-api-security