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