Translate《API Security In Action》Chapter I

第一章 什么是API安全

---

• 什么是API？

• 什么影响着API安全性？

• 根据目标定义安全

• 如何检测威胁和漏洞

• 安全API如何实现

应用程序编程接口(API) 随处可见。打开智能手机或平板电脑查看已安装的那些应用程序。几乎所有应用程序正在与一个或多个远程 API进行着通信。例如下载实时更新的内容、消息、进行轮询通知，上传我新内容等等。

使用浏览器中的开发者工具F12，然后进行网页的加载，在网络选项卡上可以看到数十个API的请求调用来向用户呈现出一个完整的高度定制后的页面（无论这个页面好不好看）。

在服务器端，这些API也可以以微服务的形式实现内部的相互调用，来实现更复杂的业务需求。

在现代生活中，我们日常使用的物联网产品家具也越来越多的与云服务API进行通信，大到冰箱彩电，小到灯泡扬声器。越来越多的云端和设备本身的API构成了逐渐庞大的物联网（IOT）。

虽然API的广泛应用逐渐使得应用程序越来越庞大，逻辑架构越来越复杂，提供的服务越来越晚上的同时，API本身也带来了更大的风险攻击面。当我们的生活和工作中更加依赖API，API由于其易用易维护的特性，越来越被程序开发者广泛使用，也就使得他们的应用程序更容易被攻击者攻破。

这本书主要讲解了如何保护API避免成为脆弱的攻击面，实现更安全的配置以更好的暴露在公网为应用程序以及用户提供更好的服务。

一、什么是API？

---

API（Application Programming Interface，应用程序接口）是一些预先定义的接口（如函数、HTTP接口），或指软件系统不同组成部分衔接的约定。 用来提供应用程序与开发人员基于某       软件       或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。

1.API Styles

API 分类：

• lRPC API 作为服务端对外暴露一组程序或功能，客户端可以通过网络进行远程调用。客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。RPC API通常适用于二进制数据流的传输，但是通常需要客户端在本地安装特定的依赖库。例如Google的gRPC框架。SOAP使用XML进行API通信的框架仍旧被广泛部署。

• lRMI。RMI曾被广泛使用，例如CORBA、EJB等，通常存在于大型企业应用系统中。

• lRESTful API 。RESTful 是目前最流行的 API 设计规范，用于 Web 数据接口的设计。（比较适合大型项目、多团队合作项目）。与RPC相比，RESTful  API强调标准消息格式与少量通用操作，减少程序的耦合性。

• l另一些API的主要致力于大数据大数据的高效查询方面。例如SQL 数据库查询以及GraphQL框架。用户只需要调用一些简单的API就可以实现复杂的查询语言。

不同的API适用于不同的环境。例如，采用微服务体系结构的公司可能会选择高效的RPC框架，以减少API调用的开销。这样做很合理，因为该公司本身控制该内网中的所有客端和服务端，并且可以在需要时管理分发新的客户端依赖。另一方面，需要暴露在公网，供普通用户使用的公共API可能更适合RESTful API，使用通用的格式（如JSON）最大限度地提高与不同类型客户端的互操作性。

在微服务体系结构中，应用程序为降低其自身的耦合，而不是将应用部署成单个大型应用程序或整体。每个微服务都提供了一个与其他服务通信的API。本书第4部分详细介绍了安全微服API。

本书将重点介绍使用 基于HTTP通信的RESTful API，因为这是编写本书时API的主要风格。尽管本书中开发的API将尝试遵循REST设计原则，但有时也会为了保护API的安全性而偏离规范。

二、Context 中的API安全

---

API安全位于多个安全分类的交叉点，如图1.2所示。其中最重要为以下三个方面：

• l信息安全（InfoSec）涉及在信息的整个生命周期内保护信息，使其不受创建、存储、传输、备份和最终销毁的影响。

• l网络安全涉及保护网络传输中的数据和防止未经授权访问网络本身。

• l应用程序安全（AppSec）确保软件系统的设计和构建能够抵御攻击和误用。

这三个主题中的每一个都分别有很多书来描述了，因此我们将不全面深入地介绍每一个主题。如图1.2所示，您不需要了解这些主题的各个方面，就可以知道如何构建安全的API。相反，我们将从每一个领域中挑选最关键的领域，并将它们混合在一起，让您彻底了解它们如何应用于保护API。

• l通过信息安全，您将了解如何：

• l定义企业的安全规范并识别威胁

• l使用访问控制技术保护API

• l使用应用密码学保护信息

密码学是一门保护信息的科学，这样两个或两个以上的人就可以进行通信，而不会被其他人读或读。它还可用于保护写入磁盘的信息。

通过网络安全，我们将了解：

• linternet上一些通用的用于保护API安全的基础架构，例如防火墙、负载平衡器和反向代理等，以及它们在保护API中所起的作用（请参阅下一节）

• l使用安全通信协议（如HTTPS）来保护向API数据传输

• 正常的HTTP请求和响应对任何可以获取网络流量的人都是以明文方式呈现，但HTTPS保护了这些信息。在第3章中，您将学习如何为API启用HTTPS。

最后，从应用程序安全性中将了解：

• l安全编码技术

• l常见软件安全漏洞

• l如何存储和管理用于访问API的系统和用户凭据

1.API的典型部署

API由运行在服务器上的应用程序代码实现。API服务直接暴露于internet比较罕见。对API的请求通常会在到达API服务器之前通过一个或多个附加网络服务，如图1.3所示。每个请求将通过一个或多个防火墙，防火墙以相对较低的级别检查网络流量，阻止一些恶意流量。例如，如果API在端口80（HTTP）和443（HTTPS）上服务请求，那么防火墙将配置为阻止任何其他端口的任何请求。然后，负载平衡器将流量路由到适当的服务，并确保一台服务器不会因大量请求而过载，而其他服务器则处于空闲状态。最后，反向代理（或网关）通常放置在应用服务器前面，以执行计算代价高昂的操作，如处理TLS加密（称为SSL终止）和验证请求凭据。

除了这些基本要素之外，还可能会遇到一些更专业的服务：

• lAPI网关是一种专门的反向代理，它可以使不同的API对外显示为一个API。它们通常在微服务体系结构中使用，以简化呈现给客户端的API。API网关通常还可以提供身份验证或速率限制功能。

• lweb应用程序防火墙（WAF）在比传统防火墙更高的级别上检查流量，可以检测和阻止许多针对HTTP web服务的常见攻击。

• l入侵检测系统（IDS）或入侵预防系统（IPS）监视内部网络中的流量。当它检测到可疑的活动模式时，它可以发出警报或主动阻断可疑的流量

在实践中，上述服务之间往往有一些重叠。例如，许多负载平衡器还能够执行反向代理的任务，例如终端TLS连接，而许多反向代理也可以用作API网关。某些更专业化的服务可以解决更多安全问题。我们将在本书中学习的许多安全机制，网关或反向代理进行多任务处理变得越来越常见。

上述组件的功能是有限的，API中糟糕的安全实现甚至会破坏最复杂的网关。配置不当的网关也会给企业网络带来新的风险。了解这些产品使用的基本安全机制将帮助我们评估产品是否适合，更全面的了解其优势和局限性。

三、API 安全要素

---

API本质上定义了一组允许调用的方使。如果不希望用户执行某些操作，只需将其从API中排除即可。那么，为什么我们需要关心API的安全性呢？

• l首先，具有不同权限级别的用户可以访问相同的API；例如，某些操作只允许管理员或具有特殊角色的其他用户执行。该API也可能暴露给互联网上根本不应该有任何访问权限的用户（和机器人）。如果没有适当的访问控制，任何用户都可以执行任何高权限账户的操作。

• l第二，虽然API中的每个操作本身可能是安全的，但API配合起来就可能存在问题。例如，银行API取款和存款操作，分别检查是否超过限额。但存款业务无法知道存款是否来自真实账户。更好的API将提供一个转账操作，在单个操作中将资金从一个帐户转移到另一个帐户，从而确保始终存在相同数量的资金。API的安全性需要作为一个整体来考虑，而不是作为单个操作来考虑。

• l最后，根据API的具体实现，可能存在某些安全漏洞。例如，未能检查API输入的size可能会允许攻击者通过发送超大数据来消耗内存；也就是拒绝服务（DoS）攻击。

一些API设计更加具有安全性，有一些工具和技术可以增加API的安全性。在开始编写代码之前考虑安全开发要容易得多（也便宜得多），而不是等到开发或生产中发现安全缺陷后再考虑。回顾性地改变设计和开发生命周期以考虑安全性虽然是可行的，但并不容易的。本书将向您介绍保护API的实用技术，但如果想从一开始就更全面地了解如何进行安全设计，那么我推荐Dan Bergh Johnson、Daniel Deogun和Daniel Sawano（Manning，2019）的《设计安全》一书。但是要记住，没有绝对安全的系统，甚至没有“安全性”的单一定义。安全是相对的，在设计更安全API时，应考虑更多方面，包括：

• l要保护的资产，包括数据、资源和物理设备

• l帐户名称的机密性

• lAPI运行的环境以及该系统中可能存在的威胁

1.资产

对于大多数API，资产由信息组成，例如客户名称和地址、信用卡信息和数据库内容。如果存储有关个人的信息，特别是可能敏感的信息，如性取向或政治派别，则这些信息也应被视为需要保护的资产。

还需要考虑物理资产，例如物理服务器或API正在运行的设备。对于在数据中心运行的服务器，物理保护（围栏、墙壁、锁、监控摄像头等）以及对在这些环境中工作的员工的审查和监控的存在，入侵者窃取或损坏硬件本身的风险相对较小。但是，攻击者可以通过攻击操作系统或软件来控制服务器。简而言之，任何与系统相关的、对某人有价值的东西都应该被视为资产。换言之，如果任何人在系统的某个部分遭到破坏时会遭受实际或感知的伤害，则该部分应被视为需要保护的资产。这种伤害可能是直接的，如金钱损失，也可能是更抽象的，如名誉损失。例如，如果没有适当的保护用户的密码，并且这些密码被攻击者窃取，用户的个人帐户可能会受到直接伤害，但如果您知道您没有遵守基本的安全预防措施，您的组织也会遭受声誉损失。

2.安全目标

安全目标用于定义安全对保护资产的实际意义。安全没有单一的定义，有些定义甚至可能是矛盾的！您可以根据系统的正确操作应该实现或保持的目标来分解安全性的概念。安全三要素：

• l私密性——避免未经授权的

• l完整性——避免未经授权的更改

• l可用性——对授权实体随时可用

尽管这三个属性很重要，但在不同的生产中，还有其他安全目标可能同样重要，例如问责（谁做了什么）或不可否认（不能否认已经执行了操作）。在开发示例API的各个方面时，我们将深入讨论安全目标。安全目标可以视为非功能性需求（NFR），与其他NFR（如性能或可靠性目标）一起考虑。与其他NFR一样，很难准确定义何时满足安全目标。很难证明安全目标从未被违反，因为这涉及到证明否定性，但也很难量化“足够好”的保密性是什么。密码学中使用了一种使安全目标精确的方法。在这里，安全目标被视为攻击者和系统之间的一种游戏，攻击者被赋予各种权力。保密性的标准游戏称为不可区分性。在这个游戏中，如图1.4所示，攻击者给系统两条等长的消息，A和B，由他们选择，然后系统返回其中一条或另一条的加密。如果攻击者能够确定A或B中的哪一个被还给了他们，那么他们将赢得比赛。如果没有一个真实的攻击者有超过50:50的正确猜测机会，那么系统就被称为安全的（对于这个安全目标）。

并不是每种情况都能像密码学中描述的那样精确。另一种方法是将更抽象的安全目标细化为具体的需求，这些需求如果足够具体就可以进行测试。例如，即时消息API可能存在用户能够读取其消息的功能要求。为了保持机密性，可以添加限制，即用户只能阅读自己的邮件，并且用户必须先登录才能阅读自己的邮件。在这种方法中，安全目标成为对现有功能需求的约束。这样就更容易想出测试用例了。例如：

• l创建两个用户并模拟通信。

• l检查第一个用户是否无法读取第二个用户的消息。

• l检查未登录的用户是否无法读取任何消息。

还没有通用的方法可以将安全目标分解为具体的需求，因此随着时间的推移，约束变得越来越清晰，该过程始终是一个迭代和细化的过程，如图1.5所示。在确定资产和定义安全目标之后，您将这些目标分解为可测试的demo。然后，在实现和测试这些demo时，可以确定要保护的新资产。例如，在实现登录系统后，可以为每个用户提供一个唯一的临时会话cookie。这个会话cookie本身就是一个应该保护的新资产。会话cookie将在第4章中讨论。这个迭代过程表明，安全性不是一个一次性的过程，正如不会只测试一次API的性能一样，应该定期重新检查安全目标和测试demo，以确保API依旧安全。

3.环境和威胁模型

对API安全性的良好定义还必须考虑API的操作环境和在该环境中可能存在的潜在威胁。威胁是指可能违反一项或多项资产安全目标的任何方式。网络世界危机四伏，要防止所有攻击几乎不可能，也不经济。在某些环境中，有些威胁不值得担心。

德怀特·D·艾森豪威尔 (Dwight D. Eisenhower) 有一句名言： 

计划一文不值，但计划就是一切。

威胁建模通常就是这样。事先考虑系统中的威胁和弱点的过程势必会提高API的安全性。进行威胁建模的方法有很多，但一般流程如下：

• l绘制一个系统图，显示API的主要逻辑组件。

• l确定系统各部分之间的信任边界。信任边界内的所有内容都由同一所有者控制和管理。

• l绘制箭头以显示数据如何在系统的各个部分之间流动。检查系统中的每个组件和数据流，并尝试识别在每种情况下可能破坏您的安全目标的威胁。特别注意跨越信任边界的流。（有关如何做到这一点，请参阅下一节。）

• l记录威胁，以确保对其进行跟踪和管理。

345在步骤1到步骤3中生成的图称为数据流图，图1.6给出了一个虚构的比萨饼订购API示例。API由运行在web浏览器中的web应用程序访问，也可由本机应用程序访问，因此这两个应用程序都在各自的信任边界中作为进程绘制。API服务器与数据库运行在同一个数据中心，但它们作为不同的操作系统帐户运行，因此可以进一步划定信任边界。请注意，操作系统帐户边界嵌套在数据中心信任边界内。对于数据库，我将用户与DBMS API的分开，提高了数据库安全性。

STRIDE：

• lSpoofing—冒充他人篡改数据

• lTampering—更改不应更改的数据、消息或设置  

• lRepudiation— 否认你做了你真正做过的事情

• lInformation disclosure—透露应保密的信息 

• lDenial of service—影响他人访问信息和服务  

• lElevation of privilege—访问不应该访问的功能

STERE首字母缩略词中的每个首字母都分别表示对API的一类威胁。通用安全机制可以有效应对每一类威胁。通过应用一些基本的安全机制，可以完全消除（或至少显著减轻）许多常见的API安全威胁，如第3章和本书其余部分所示。

四、安全机制

---

可以通过应用安全机制来应对威胁，以确保满足特定的安全目标。在本节中，我们将介绍您通常会在每个精心设计的API中找到的最常见的安全机制：

• l加密确保数据不会被未经授权的方读取，无论是在从API传输到客户端时，还是在数据库或文件系统中静止时。现代加密还确保数据不会被攻击者修改。

• l身份验证是确保用户和客户与他们所说的相同的过程。访问控制（也称为授权）是确保向API发出的每个请求都得到适当授权的过程。

• l审计日志记录用于确保记录所有操作，以允许对API进行帐户功能和适当的监控。

• l速率限制用于防止任何一个用户（或用户组）使用所有资源，并防止合法用户访问。

1.加密

数据可能存在风险的主要情况有两种：

• lAPI的请求和响应在网络（如internet）上传输时可能存在风险。加密传输中的数据用于防范这些威胁。

• l有权限访问系统文件的人员可能会对数据造成风险。对静态数据进行加密是为了防止这些威胁。

TLS应用于加密传输中的数据，详见第3章。第12章讨论了受约束设备的TLS替代方案。在休息时加密数据是一个复杂的话题，需要考虑很多方面，这在很大程度上超出了本书的范围。第5章讨论了数据库加密的一些注意事项。

2.识别和认证

身份验证是验证用户是否是合法用户。我们通常关心的是识别用户是谁，但在许多情况下，最简单的方法是让客户告诉我们他们是谁，并检查他们说的是真话。当你在公园里看到你的老朋友爱丽丝时，你马上就知道她是谁，因为她有着共同的交往历史。如果你向老朋友索要正式身份证明，那就太奇怪了（更不用说粗鲁了）！另一方面，当你参加驾驶考试时，考官要求看你的驾驶执照也就不足为奇了。考官可能以前从未见过你，而驾驶考试是一种情况，在这种情况下，某人可能会合理地谎报自己是谁，例如，为了让更有经验的司机为他们参加考试。驾驶执照证明你是一个特定的人，考官相信它，因为它是由官方机构颁发的，很难伪造。

有很多种方法验证的用户： 

• l用户知道的东西，例如密码  

• l用户拥有的东西，例如钥匙或物理设备  

• l用户本身，这是指生物识别因素，例如指纹虹膜等

任何单一的认证因素都可能受到影响。人们选择弱密码，或将其写在电脑屏幕上的便笺上，并错误地放置物理设备。尽管生物特征因素很有吸引力，但它们通常有很高的错误率。因此，最安全的身份验证系统需要两个或多个不同的因素。例如，您的银行可能要求您输入密码，然后使用带有银行卡的设备生成唯一的登录代码。这就是双因素身份验证（2FA）或多因素身份验证（MFA）。

注意，身份验证因素不同于凭证。使用两个不同的密码进行身份验证仍然是一个因素，因为它们都是基于用户所知道的内容。

3.访问控制与授权

为了保护资产的机密性和完整性，通常需要控制谁有权访问什么以及允许他们执行什么操作。例如，消息传递API可能希望强制用户只允许阅读自己的消息，而不允许阅读其他任何人的消息，或者他们只能向其友谊组中的用户发送消息。

注意，在这本书中，我使用了授权和访问控制这两个术语，因为这是它们在实践中经常使用的方式。一些作者使用术语访问控制来指整个过程，包括身份验证、授权和审核日志记录，简称AAA。

API主要使用两种访问控制方法：

• l基于身份的访问控制首先识别用户，然后根据用户的身份确定他们可以做什么。用户可以尝试访问任何资源，但可能会根据访问控制规则拒绝访问。

• l基于角色的访问控制使用称为能力的特殊令牌或密钥来访问API。该功能本身表示承载者可以执行哪些操作，而不是用户是谁。角色既可以命名资源，也可以描述资源的权限，因此用户无法访问任何他们没有权限访问的资源。

第8章和第9章详细介绍了访问控制的这两种方法。

其实甚至可以将应用程序及其API设计为完全不需要任何访问控制。wiki是Ward Cunningham发明的一种网站类型，用户在其中协作撰写关于某个或多个主题的文章。最著名的维基百科是维基百科，这是一种在线百科全书，是网络上浏览量最大的网站之一。wiki的与众不同之处在于它完全没有访问控制。任何用户都可以查看和编辑任何页面，甚至可以创建新页面。wiki提供了广泛的版本控制功能，可以轻松撤消恶意编辑，而不是访问控制。编辑的审核日志提供了责任，因为很容易看到谁更改了什么，并在必要时恢复这些更改。社会规范的发展是为了阻止反社会行为。即便如此，像Wikipedia这样的大型维基通常都有一些明确的访问控制策略，以便在两个用户意见严重不一致或持续故意破坏的情况下，可以暂时锁定文章，以防止“编辑大战”。

4.审计日志

审计日志的目的是确保问责制。它可以在安全漏洞发生后用作溯源的一部分，以找出问题所在，还可以通过日志分析工具实时分析正在进行的攻击和其他可疑行为。一个好的审计日志可以用来回答以下问题：

• l谁执行了操作以及他们使用了什么客户端？ 

• l何时收到请求？ 

• l它是什么类型的请求，例如读取或修改操作？ 

• l正在访问什么资源？ 

• l请求成功了吗？如果不是，为什么？ 

• l用户在同一时间还访问了什么？

5.限速

我们将考虑的最后一种机制是在面对恶意或意外DoS攻击时保持可用性。DoS攻击的工作原理是耗尽API为合法请求提供服务所需的有限资源。这些资源包括CPU时间、内存和磁盘使用率、电源等。通过用虚假请求淹没您的API，这些资源将被占用，无法服务于其他请求，而只能服务于这些请求。除了发送大量请求外，攻击者还可能发送占用大量内存的过大请求，或者发送请求的速度非常慢，因此资源会被占用很长时间，而恶意客户端无需花费大量精力。抵御这些攻击的关键是要认识到客户端（或客户端组）使用的资源超过了它们的合理份额：时间、内存、连接数等等。通过限制任何一个用户可以使用的资源，我们可以降低攻击的风险。一旦用户通过身份验证，您的应用程序就可以强制执行配额，限制他们可以执行的操作。例如，您可以将每个用户限制为每小时一定数量的API请求，以防止他们用过多的请求淹没系统。出于计费目的以及安全利益，经常有业务原因这样做。

在用户登录之前，可以应用更简单的速率限制来限制总体请求数，或限制来自特定IP地址或范围的请求数。要应用速率限制，API（或负载平衡器）会跟踪每秒服务的请求数。一旦达到预定义的限制，系统将拒绝新请求，直到速率回落到该限制之下。速率限制器可以在超过限制时完全关闭连接，或者减慢请求的处理，这一过程称为节流。当分布式DoS正在进行时，恶意请求将来自不同IP地址上的许多不同计算机。因此，能够将利率限制应用于整个客户群而不是单个客户是很重要的。速率限制尝试确保在系统完全崩溃和完全停止运行之前拒绝大量请求。

原文始发于微信公众号（赛博少女）：Translate《API Security In Action》Chapter I