REST API 面临的 7 大安全威胁

互联网安全是技术博客和论坛讨论得越来越频繁的一个话题，并且理由充分：近年来，众多引人注目的安全漏洞显著增多。安全性非常重要，特别是在 REST API 领域。

API 安全性是组织希望在未来几年内解决的最大挑战，而安全性挑战的解决很有可能会成为 API 领域增长的催化剂。

根据Jitterbit发布的2018年API集成状况报告：

API 正在改变业务

今天，令人印象深刻的是有 64%的组织正在创建用于内部或外部用例的 API。虽然有四分之一的受访者现在根本没有创建 API，但 40%的受访者都利用了内部和外部用例中的 API。

API 的创建和管理由开发人员负责

如今，大多数利用 API 的组织都依赖他们的开发人员来编写和管理这些 API。尽管 33%的受访者使用专门的技术来管理他们的 API，但 90%的受访者依靠他们的开发团队或外部资源从零开始编写 API。

组织已经被越来越多新的云应用程序之间的代码集成压得喘不过气来，它们对开发人员提出更多要求，要求他们为业务创建和管理API。

REST API 的安全性

在设计、测试及部署 REST API 时，安全性问题是一个必须要考虑的重要方面。随着 REST API 的飞速发展，在大多数情况下，安全级别在 API 的设计和开发中被低估。目前敏感数据（无论是组织信息还是个人信息）的安全性是困扰开发人员的一个重要因素。REST API 也不例外，它是需要防范安全威胁和漏洞的重要系统的一部分。

据 2018 年Postman社区报告（调查）显示，越来越多的开发者开始关注 REST API 的安全性，并且对 REST API 的信任度也比前一年有所提高：

在本文中，我将介绍当今 IT 界的 7 大 REST API 安全威胁，以引起大家的关注，并帮助大家了解那些能够反映 REST API 性能的安全威胁。

REST 的安全性问题。

REST 通常使用 HTTP 作为其底层协议，这带来了一系列常见的安全性问题：

• 潜在的攻击者可以完全控制 HTTP 请求或 HTTP 响应的每个字节。由于 REST API 通常用于交换在许多服务器中保存执行的信息，因此它可能会导致一些未经发现的漏洞和信息泄漏。

• 攻击者可能在客户端（REST API 的消费者，而受害者是 REST API 服务器）也可能在服务端（攻击者获得了对 REST API 服务器的控制权）创建一个恶意的流氓应用程序。在这种情况下，使用远程 REST API 服务消费资源的应用程序是受害者。

• 对使用 REST 作为客户端或服务端的应用程序，另一方通常完全控制资源，并可以注入任何负载来攻击资源处理（例如，获取任意 Java 代码或系统命令执行）。

在 REST 架构中，端到端的处理意味着包含一系列潜在的易受攻击的操作：

• 在往返于 HTTP 消息和资源 URL 的映射过程中（控制器映射）。

• 当实例化表示目标资源的对象并调用请求操作（从控制器中调用服务）时。

• 为目标资源（特定于服务的函数）生成状态表示时。

• 访问/修改托管资源状态的后端系统中的数据时（保存到数据库或存储中）。

REST 框架中的分层转换序列意味着链中的一个薄弱环节就可能会使我们的应用程序变脆弱。

7 大 REST API 安全威胁

1. 注入攻击

在注入攻击中，危险代码被嵌入到一个不安全的软件程序中，以发起攻击，其中最著名的是 SQL 注入和跨站点脚本攻击。实际上，这种暴露可以通过将不受信任的数据作为查询或命令的一部分传输到 API 中来操作。该输入随后由解释器实现，这可能会导致攻击者获取未经授权的信息访问权限或造成其他损害。

阻止或拒绝注入攻击最有效方法是添加输入验证，以下是几个最重要的准则：

• 验证输入：长度、范围、格式及类型

• 通过在 API 参数中使用强类型（如数字、布尔值、日期、时间或固定数据范围）来实现隐式输入参数校验
  

• 用正则表达式约束字符串的输入

• 定义适当的请求大小限制并使用 HTTP 响应状态 413（请求实体太大）来拒绝超过该限制的请求

2. DoS 攻击

在拒绝服务（DoS）攻击中，攻击者在大多数情况下会推送大量消息，请求服务器或网络建立由无效返回地址组成的请求。如果没有采取适当的安全防范措施，这种攻击能够使 RESTful API 处于无法运行的状态。最近，无论 API 是否公开，其他人（包括攻击者）都可以访问它。

随着这些 API DoS 攻击变得变得越来越普遍，并且随着组织越来越多地依赖 API 来满足其业务需求，安全专业人员应该开始积极计划应对此类攻击。即使禁用用于应用程序身份验证的 API 密钥（或访问令牌），也可以通过标准浏览器请求轻松地重新获取密钥。

因此，使当前访问令牌失效不是一个长期的解决方案。如果 DoS 攻击可以追溯到某个特定的 IP 地址，那么将该 IP 地址列入黑名单也不是长久之计，因为攻击者可以很容易地获取一个新的 IP 地址。

这就是为什么需要多种访问控制方法的原因。对于非敏感信息，使用 API 密钥可能就足够了。然而，为更好地防止 DoS 攻击，需要使用 HTTPS 和更健壮的身份验证机制，包括OAuth、相互（双向）TLS（传输层安全性）身份验证或SAML（安全断言标记语言）令牌。

为防止可能会导致 DDoS 攻击或其他 API 服务滥用的大量 API 请求，请在给定时间间隔内对每个 API 的请求数量施加限制（也称为峰值阻止）。当超过此速率时，至少暂时阻止来自该 API 密钥的访问，并返回 429（请求过多）HTTP 错误码。

如果我们开始构建新的REST API了，请先检查下 Web 服务是否具有一些面向安全性的特性。

3. 身份验证失败

这些特殊的问题可能使攻击者绕过或控制 Web 程序使用的身份验证方法。身份验证丢失或不足可能会导致攻击，从而破坏 JSON Web 令牌、API 密钥、密码等。

攻击的目的通常是控制多个帐户，更不用说攻击者获得与被攻击用户同等的权限。只有经过身份验证的用户才可以访问这些 API。

使用 OpenId/OAuth 令牌、PKI 和 API 密钥可以很好地满足 API 授权和身份验证需求。最好不要通过未经绑定的连接发送凭据，也不要在 Web URL 中显示会话 ID。

4. 敏感数据泄露

由于在传输中或静态时缺乏加密而导致的敏感数据暴露可能会导致攻击。当应用程序无法正确保护敏感数据时，就会发生敏感数据泄漏。这些信息可能是私人健康信息、信用卡信息、会话令牌、密码等，而且包含越多的信息越容易受到攻击。敏感数据需要很高的安全性，除了在与浏览器进行交换时采取非常规的安全做法外，还包括静态或传输中的加密。

为了避免敏感数据泄露，必须使用 SSL。

今天，我们可以通过Let’s Encrypt得到一个免费证书。SSL 和 TLS 在消除基本 API 漏洞方面经验丰富，几乎不费吹灰之力。

要想获得一份有关实施效果的出色报告，请使用Qualys SSL服务测试，测试你的 URL。这是我们的测试结果：

5. 访问控制中断

访问控制，在某些情况下称为授权，是一个 Web 软件允许某些人而不是所有人访问它的功能和内容的方式。缺少访问控制或访问控制不足可能会使攻击者可以控制其他用户帐户、变更访问权限、变更数据等。

当开发人员未能正确地配置操作级的可访问性时，公司应用程序访问就容易受到攻击，从而导致访问漏洞。拒绝访问是破坏访问控制的最常见后果，而利用访问控制是攻击者的主要手段。

由于某些框架中缺少访问控制，因此可以通过手动或自动化的方式来检测访问控制。如果在可靠的无服务器或服务器端 API 中实现了访问控制，则访问控制通常是有效的，因为攻击者将无法更改访问控制元数据。

6. 参数篡改

这是一种基于操作客户端和服务器之间交换的参数来修改应用程序数据（例如，用户凭据和权限、产品价格和数量等）的攻击。通常，这些信息存储在 cookie、隐藏表单字段或 URL 查询字符串中，用于增强应用程序的功能和控制。

当有害的网站、程序、即时消息、博客或电子邮件使用户的 Internet 浏览器在授权的网站上执行不必要的操作时，就会发生这种情况。它允许攻击者在被攻击用户不知情的情况下，使用目标的 Web 浏览器使目标系统执行某个功能，直到未经授权的事务被执行为止。

攻击能否成功取决于完整性和逻辑验证机制的错误，利用该机制可能还会导致其他攻击，包括 XSS、SQL 注入、文件包含和路径泄漏等攻击。

我们应该仔细地校验接收到的 URL 参数，以确保该数据能代表来自用户的有效请求。无效请求可用于直接攻击 API 或攻击 API 背后的应用程序和系统。将校验器放在应用程序上，并尝试对发送到 REST API 的请求使用 API 签名。还可以为API创建自动化安全测试，以确保没有参数篡改来影响我们的 REST API。

7. 中间人攻击(MITM)

它是指攻击者秘密地更改、拦截或中继两个交互系统之间的通信，并拦截它们之间传递的私有和机密数据。MITM 攻击分为两个阶段：拦截和解密。

HTTP 且缺少 TLS

API 中缺少传输层安全性（Transport Layer Security，TLS）实际上等同于向黑客发出公开邀请。传输层加密是安全 API 中最基本的“必备条件”之一。除非使用 TLS，否则遭受普遍存在的“中间人”攻击的风险仍然很高。在 API 中同时使用 SSL 和 TLS 很有必要，尤其是要使用公开 API​​时。

总结

在开发 REST API 时，必须从一开始就注意安全性。可以考虑使用内置了许多安全特性的现有 API 框架。在 RestCase 中，我们使用的是SugoiJS API框架，除测试和安全指导之外，我们还为其代码库做出了贡献。通过这种方式，安全性被统一地内置，并且开发人员可以更专注于应用程序的逻辑。

在这之后，不要忘记分配资源来测试 API 的安全性。一定要测试本文中所提到的所有安全威胁。

原文链接：

Top 7 REST API Security Threats