REST API面临的7大安全威胁

近年来，互联网上安全漏洞显著增多。互联网安全的话题也被技术博客和论坛讨论得越来越频繁:安全性非常重要，尤其是在REST API的世界中。

根据Jitterbit公司2018年API集成状态报告:

APIs 正在改变商业

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

API的创建和管理落到了开发人员的肩上

如今，大多数利用APIs的组织都依赖开发人员来编写和管理这些api。33%的受访者使用专门的技术来管理APIs，而90%的受访者则依赖开发团队或外部资源从头开始编写APIs。

由于在越来越多的新的云应用程序之间编写集成代码，组织已经不堪重负，因此要求开发人员为业务创建和管理APIs。

REST API安全

在设计、测试和部署REST API时，安全性问题必须是需要考虑的重要方面。随着REST API的惊人发展，安全级别，大部分时间，在API的设计和开发中被低估了。敏感数据的安全性，无论是组织的还是个人的信息，都是当今困扰开发人员的一个重要因素。REST api也不例外，它是需要针对安全威胁和破坏进行保护的基本系统的一部分。

根据2018年Postman community report (survey)，越来越多的开发者开始关注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架构中，端到端处理意味着一系列潜在的脆弱操作：

• 在进行 from/to the HTTP 消息映射 和资源 URL (controller 映射).
• 实例化表示目标资源的对象并调用所请求的操作时(从控制器调用服务)。
• 在为目标资源(特定于服务的功能)生成状态表示时。
• 当访问/修改托管资源状态(保存到数据库或存储中)的后端系统中的数据时。

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(安全断言标记语言)令牌。

为了防止大量API请求导致DDoS攻击或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. 中间人攻击( Man-In-The-Middle-Attack)

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

HTTP和缺乏TLS

在API中缺少传输层安全(TLS)实际上相当于向黑客发出公开邀请。传输层加密是安全API中最基本的“必备功能”之一。除非使用TLS，否则相当常见的“中间人”攻击的风险仍然很高。在api中同时使用SSL和TLS，特别是在API公开的情况下。

结论

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

在这之后，不要忽略分配资源来测试API的安全性。确保测试本文中提到的所有安全威胁。