什么是API安全

章节概述

• 什么是API
• 导致API安全或不安全的因素
• 定义安全的目标
• 识别威胁和漏洞
• 达到安全目标的机制

应用程序接口（API）随处可见。当你打开智能手机或平板，浏览上面安装的应用时，差不多这些应用都会连接一个或多个远程API，通过这些接口下载最新的内容和信息、轮询通知、上传你发送的内容或者执行你要求的操作。

如果你在浏览器中使用开发工具打开你最喜欢的网页，那么你一定能看到为了渲染一张为你定制的网页，浏览器在后台调用了很多API。而在服务器内，为了响应浏览器调用的API，可能会导致许多微服务调用内部的API来相互通信。

甚至更多时候，你在家里的日常生活也会使用许多API。从微信视频通话到使用冰箱、电表和灯泡，都是在通过API使用。由于云端API和设备API的快速增加，也促进了物联网在消费品业和工业的快速落地。

虽然API的广泛使用让各种应用更加精巧地改善我们的生产和生活，但是也会导致风险的提升。随着我们在工作或娱乐中更加依赖通过API来处理关键事务，我们也更容易因为API遭受攻击而被影响。应用API场景越多，被攻击的可能性就越高。API因为使用方便而被开发者青睐，也因此容易被怀有恶意的人攻击。另外，一些新出台的隐私与数据保护法规，比如欧盟的GDRR，对公司保护用户数据提出了法律规范。如果公司被发现对数据没有充分的保护，将面临惩罚。

GRDD

General Data Protection Regulation/通用数据保护条例（GDPR），2018年生效，是欧盟法律的重要组成部分。该法律的主要目的是通过技术和祖师手段，保证欧盟公民的个人数据不会滥用，并受到充分的保护。其中就包括本书涉及的安全控制。还包括隐私技术，比如姓名和其他个人信息的化名（本书中不涉及），以及要求在收集或共享个人数据之前需要用户的明确许可。该法律要求公司发生数据泄漏后72小时内必须上报，范围该法律会导致最高两千万欧元（准确地说是两千三百六十万欧元）或者公司全球年营收4%的罚款。其他司法管辖区也在效仿欧盟，出台类似的隐私和数据保护立法。

本书主要关于如何在上述威胁中保护你的API，让你放心的对外提供这些API。

1.1 举个栗子：驾驶考试

我们以实际场景——驾照考试来类比API安全。尽管这个故事开始的时候会让人觉得和API或者安全毫无关系，但最终你会发现这个故事各方面和本章将要讲述概念都有相似之处。

假设你今天5点下班，但没有像平常那样回去照顾你养的是肉植物然后摊在电视前，而是去了别的地方。今天要参加驾驶考试。

你冲出办公室，打算穿过公园去搭公交到考试中心。当你路过热狗摊前排队的人群时，看到了你的老朋友Alice在溜她的羊驼，Horatio。

你高兴的招呼她：“Alice，18世纪巴黎里的活动好玩吗？”

“好玩的！”她回答道，“推荐你去体验下”。

她比划了个全球通用的手势，“到时候给我打电话”。你们就先去忙各自的事儿了。

你被夹在拥挤的公交车里到了驾考中心，心里一直抱怨“要是我能开车，要遭这个罪？！”。在驾考中心等了一会，监考员出来了，向你简单的介绍下自己，并要求查验你的准考证拍摄准考证照片的时候，你还留着自以为很帅实际很丑的发型，监考员怔了半晌才认出来照片上确实是你，最终同意你参加考试。

相关学习  大部分API都需要识别和它们交互的客户的身份。和场景中一样，识别客户身份的方式有很多。基于以往的交互历史，可以建立长期的信任关系，就好象你和Alice那样；而有些情况则需要提供更加正式的身份证明，比如展示准考证，因为准考证是由可信任的机构颁发的，而你长得和照片上差不多，所以监考员信任它。

有些API只需要低等级的身份证明就可以操作，有的需要高等级的身份证明。

最终，你没考过，所以你只能搭火车回家。你买了一张到你住的街区的二等坐票，但感觉坐着不爽，所以想溜进一等座车厢。结果被乘务员拦住要看你的车票。于是你又顺从的溜回自己的座位，假装带上了耳机。

当你回到家，发现自己电话上的留言指示灯在闪。它要是不闪，你都不知道他是个电话。你听了留言，是Alice邀请你去城里面新开的俱乐部。你觉得晚上出去浪一浪可以抚慰萎靡的情绪，所以你赶去了。

看门的瞅了你一样。

“今天不开门。”她冷漠地说。

这个时候，来了位明星，看门的毕恭毕敬地把他迎了进去。然后出门告诉你今天不开门，你只好回家。

你觉得自己需要休个假冷静下，于是定了两周的豪华酒店。走之前，你把家里面热带植物园的钥匙留给了邻居Bob，委托他帮你照看你养的食肉植物。结果，Bob在你离开以后，邀请全村的人去你的植物园开party。好在他们饮料喝完就散了，没找到你所在家里面的珍藏威士忌。

相关学习  识别出用户的身份，API还需要判断这个用户可以执行什么等级的操作。这种判断可以基于用户的身份，比如明星可以进入俱乐部；或者基于有时间限制的票据，比如火车票；或者长期有效的钥匙，比如你留给邻居的植物园钥匙。每种判断方式都各有利弊。比如钥匙失窃，会让其他人也可以进入。另外，也可以为不同的锁（或不同的操作）配执不同的钥匙，只把少量权限授予其他人。比如Bob只能进入植物园，但不能进入你家拿威士忌。

回到家以后，你查看了家里的全方位监控。默默地把给Bob买的礼物退了货，把下次得换个人照看植物园记载了小本本上。

后来你在party上遇见Bob，但是他不承认自己做过的那些事，你告诉他有监控，他承认了。后来他买了一盆捕蝇草向你赔礼道歉。监控系统展示了在发生一些不正常情况时，可以通过审阅日志查找出谁在什么时候做了什么事，这样可以在必要的时候举证。

相关学习  审阅日志记录了系统中发生的关键事件的详细信息，方便你在回溯谁在什么时间做了什么事情。审计日志是调查潜在安全漏洞的重要证据。

希望你现在可以看到一些保护API的机制，但是在深入讨论细节之前，让我们先回顾一下API是什么，以及它的安全性意味着什么。

1.2 什么是API

传统意义的API是由软件库提供的，用于在软件运行中链接静态或动态的应用，复用进程或函数以解决特定的问题。比如OpenGL提供的用于处理3D图像的API，用于TCP/IP网络编程的API等。除了这种通用的API，现在还涌现了越来越多的通过网络访问的RESTful API。

总的来说，API是软件系统中的各个部分的边界。API定义了系统中某个部分可以被其他部分调用的操作。比如，一个超片存档服务可能提供用于罗列相册的接口，浏览照片的接口、添加评论的接口等。那么一个网络画廊可以使用这些接口展现有趣的图片，一个文字处理应用可以调用这些接口把图片添加到文字中。如图1.1所示，API处理一个或多个客户端发起的请求，这些请求代表了用户的行为。客户端可能是网页应用或者是有UI/用户操作接口的移动应用，或者是其他没有UI的API。一个API可能需要访问别的API才能正常工作。

图1.1

用户操作接口/UI同样对操作系统提供了边界，并定义了可以执行的操作。UI和API区别在于，API在设计时考虑的是方便其他应用使用，而UI在设计时，考虑的是方便用户使用。UI会用表现丰富的表单展示信息，使这些信息更易于阅读和使用。而API通常会以更规范化、更容易提取的方式展示原始信息，方便别的程序解析和使用。

1.2.1 API的类型

远程API有以下几种常见类型：

• Remote Procedure Call(RPC) API: 远程过程调用接口。RPC把函数和进程通过网络暴露给客户端使用。客户端通过网络调用这些RPC时，就和调用本地的API一样。RPC接口通常使用简洁的二进制格式传递信息，非常高效。但是通常需要客户端安装专门的库(一般称为stubs)才使用某个接口。Google开发的gRPC框架是现代RPC实现方案。早期的RPC框架SOAP(Simple Object Access Protocol)，使用XML传递信息，也是现在比较常用的方案。
• Remote Method Invocation(RMI): 远程方法调用，RPC的一种变体。采用面向对象技术，是客户端可以在使用服务器上方法或对象时就好像在调用本地的方法或对象。RMI是曾经很流行的方式，CORBA以及Enterprise Jaa Beans常采用RMI构建大型企业系统。但是这些框架比较复杂，导致现在使用的较少。
• REpresentational State Transfer(REST): 由Roy Fielding开发、定义的一种规范。这些规范促成了HTTP的成功，并被成为API设计的指导原则。和RPC相比，REST API明确了信息传递的标准以及一些通常的规范，减少了客户端和特定接口之间的适配成本。同时使用超链接的方式指向API，降低了由于API迭代导致客户端无法使用的风险。
• 还有一些API专注解决大量数据的查询和过滤功能，比如SQL数据库，还有Fracebook开发的GraphQL框架。这种情况下，API通常提供丰富的查询语言结合各种操作，方便客户端准确控制返回的数据。

不同的API类型适用于不同的场景。比如，采用了微服务结构的系统更适合使用高效的RPC框架，用以降低API调用的成本。因为系统控制所有的客户端和服务，可以在需要的时候管理和添加新的stubs。而广泛使用的公共API则更适合REST类型的API，因为REST API采用广泛使用的数据格式，比如JSON，所以可以最大限度的适配各类客户端。

注释  在为服务架构中，应用由一组松散耦合的服务组成，而不是一个庞大的应用或单体应用。每个微服务都暴露别的微服务可用的API，微服务API的安全问题在本书第四部分有详细说明。

本书主要关注使用RESTful风格的HTTP接口，因为这是本书书写时最主流的API类型。所以，本书中展现的API将尝试遵循REST设计原则，但您有时会偏离这些原则来尝试如何保护其他类型的API。本书中大部分建议也使用于其他风格的API，一些通用的原则甚至可以用于库的设计。

1.3 总览API安全

如图1,2.所示，API安全基于多种安全规则的交叉。最主要的是以下三部分:

• 信息安全(InfoSec)：聚焦于信息保护，这种保护贯信息的创建、存储、传输、落还、以及最终销毁的生命周期。
• 网络安全：解决服务两方面问题，如合保护通过网络传播的数据流以及如何防止未授权的网络。
• 应用安全(AppSec)：确保设计和部署的应用可以对抗攻击、防止误用。

图片1.2.

 

以上的任意一部分都相关的书记专门介绍，所以本书不会在某一方面特别深入。如图1.2.所示，构建安全的API也不需要学习每个部分的方方面面。我们会选取每个部分最关键的方面融汇起来，帮助您深入理解这些方面如何用于保护API。

您可以通过信息安全了解到如何：

• 定义安全目标、识别威胁
• 使用访问控制技术保护API
• 使用密码学保护信息

注释  密码学是一门保护信息的学科，应用密码学，两个或多个人之间的通信的信息就不能被其他人读取或篡改。密码学也可以用于加密磁盘上的信息。

通过网络安全您可以了解到：

• 保护网络中API的基本措施，包括防火墙、负载均衡、反响代理等，以及他们在保护API中的角色(见下一小节)
• 使用安全通信协议，如HTTPS，来保护数据传输

注释  HTTPS是使用安全链接的HTTP。普通的HTTP请求和响应对任何监控网络传输的用户都可见，而HTTPS传输的信息通过安全传输层(TLS，也被称为SSL)隐藏和保护。您可以在第3章了解到如何使用HTTPS

最后您可以通过应用安全了解到：

• 安全的编码方式
• 常见的软件安全漏洞
• 如果管理用于访问API的系统和应用凭证

1.3.1 一种常见的API部署方式

API是由服务器上运行的应用代码实现的，应用可以是Java企业版(JavaEE)应用，也可以是标准的服务器软件。通常不会直接把这些服务暴露到网络中，甚至不会对内部网络直接暴露。如图1.3.所示，请求一般要经过一条或多条网络服务才能到达提供API的服务。请求需要通过一道或多道防火墙，这些防火墙在系统较低的层级会检查网络流量，并确保阻塞意料之外的流量。比如，您通过80端口(用于HTTP)和443端口(用于HTTPS)提供API，那么通过防火墙配置，可以过滤访问其他端口的请求。负载均衡负责把流量转发到合适的服务器上，避免出现某个服务器繁忙而其他服务器闲置的状态。反响代理(或称为网关)通常放置在服务的前端，用于处理一些计算成本较高的操作，比如处理TLS加密(通常称作SSL终止)或验证请求的凭证。

注释  SSL终止(或称为SSL卸载)发生在客户端发起的TLS连接在经过负载均衡或反向代理之后。SSL卸载后会建立代理服务与目标服务之间的单独连接，这次连接既可以是非加密的HTTP连接也可以是单独的TLS连接(即，SSL再加密)。

 图1.3

除了这些基本的元素，您也可能遇到一些别的专有服务：

• API网关是一种专用的反向代理，可以让不同的API通过同一个API暴露出去。API网关通常用于微服务架构中简化暴露给客户端的API。API网关也可以处理本书中讨论的API安全的一些问题，比如认证和限流。
• web application firewall(WAF)/网络应用防火墙在系统中较高的层级检查网络流量，可以删除、阻拦常见的针对HTTP网络服务的攻击。
• intrusion detection system(IDS)/入侵监测系统监控内部网络流量。当检测到可疑的行为模式，IDS可以发出警告或者尝试阻拦可疑的流量。

在实践中，这些服务之间通常会有重叠。许多负载均衡服务也可以提供反向代理的功能，比如终止TLS连接；许多反向代理服务也可以提供API网关的功能。一些专业的服务软件甚至可以实现本书中可以学到的安全机制，而且让网关或反向代理服务提供部分安全任务也越来越常见。这些组件的功能是有限的，而且API中糟糕的安全实践甚至会破坏设计轻巧的网关。而配置不当的网关则会给您的网络中引入新的风险。只有理解这些产品使用的基本安全机制，您才能评估一件产品是否适用于您的应用，特别是这件产品的优势和劣势。

小测验

1.以下哪些内容和API安全直接相关？(多选)

        a 工作安全

        b 国家安全

        c 网络安全

        d 经济安全

        e 应用安全

        f 信息安全

2.API网关是下列那种组件的专用版本？

        a 客户端

        b 数据库

        c 负载均衡服务

        d 反向代理

        e 应用服务

答案在章节末。

1.4 API安全的元素

API本就是为调用者定义的一组操作，如果您不希望某位用户之行某些操作，为什么不单纯的把这个操作从API中剔除，而是要考虑API安全呢？

• 首先，权限不同的用户可能会访问相同的API。比如，某些操作只允许管理员或拥有特殊角色的用户执行。但是这个API也会暴露给网络上不应该访问它的用户和程序。如果没有合适的访问控制，那么任何用户都可以执行任何操作，显然不是我们想要的。因为API运行在网络中，所以需要。
• 第二，即使每个API的操作是安全的，当他们被组合起来就不一定安全。比如，银行的API可能会分别提供取款和存款API，这两个API会分别检查金额不能超出限制。但存款业务无法知道所存资金是否来自真实账户。更好的API设计会提供一个用于转账的操作，在这个操作中将资金从一个帐户转移到另一个帐户，保证金额的总量始终相等。需要从整体考虑API的安全性，而不是分别考虑。
• 最后，使用API也可能存在安全漏洞。比如，没有检查API的输入可能会让攻击者通过发送大量的输入数据，导致您的服务器内存占满，最终服务宕机，这是常见的denial of service(DoS)/拒绝服务 攻击。

注释  拒绝服务攻击指攻击者阻止合法用户访问服务。常见做法是段时间向服务器注入大量流量导致合法用户不能正常请求服务，也可以通过断开网络连接或利用漏洞使服务器崩溃来实现。

一些API设计比其他API设计更容易保证安全，并且有一些工具和技术可以帮助确保安全实现。在开始编码之前考虑安全开发要比等到开发或生产过程中发现安全缺陷时再考虑安全开发容易得多（也便宜得多）。虽然可以通过重构设计、修改开发的生命周期来实现API安全，但这种做法并不容易。本书会教授您一些保证API安全的实践技术，但如果您想更深入的了解如何从头设计安全性，那么我推荐您阅读Dan Bergh Johnsson，Daniel Deogun 和 Daniel Sawano编著的Secure by Design。

重要的是要记住，没有完全安全的系统，甚至“安全”本身也没有统一的定义。对于医疗保服务来说，能够发现你的朋友是否在系统上有帐户，会被视为一个重大的安全漏洞和隐私侵犯。但对于社交平台来说，这是基本的要求。因此安全和服务所在的场景相关。在设计API时，需要考虑多方面问题，其中包括一下方面：

• 需要保护的财产，包括数据、资源、物理设备等
• 哪些安全目标是重要的，比如账户名称的保密性
• 为了达成安全目标哪些机制是可以实现的
• API将在什么样的环境中操作，该环境中存在哪些威胁

1.4.1 资产

对于大多数API，资产指的是信息，比如用户的名称、地址、信用卡信息以及数据库内容。如果i你存储了个人信息，特别是敏感信息，比如性取向或政治立场，那么这些信息应该被是为资产并保护起来。

除此之外，物理资产也需要考虑，比如运行您的API的物理服务器或设备。对于数据中心的服务器而言，由于有物理的防护(墙、锁、监控等)以及对工作人员行为的监控，发生盗窃或硬盘损毁的风险较低。但攻击者可能会通过操作系统漏洞或软件的漏洞获取对硬盘中资源的控制权。如果他们可以在上面安装自己的软件，甚至可以停止您的合法软件，转而让服务器执行他们定义的行为。

简言之，任何连接在您服务器上、对他人有价值的事物都应该视为资产。而如果您服务器中的某一部分受到损害会导致其他人受到真实的伤害，那么这一部分该视作需要被保护的资产。这些对他人的伤害可以是直接的，比如损失钱财；也可以是抽象的，比如名誉受损。举例来说，如果您没有保护好用户的密码，那么用户会因为他们的个人账户丢失而收到损失，您的组织也会因为没有遵守基本的安全准则而声誉受损。

1.4.2 安全目标

安全目标用于定义安全对于保护资产的实际意义。安全没有统一的定义，有些场景中的定义可能是冲突的。从系统正确运行时希望达到或保持的安全目标出发，您可以拆分安全目标。一些标准的安全目标几乎适用于所有的系统，其中最著名的是“CIA三元组”：

• Connfidentiality / 保密性：确保只有正确的用户可以读取到信息
• Intergity / 完整性：防止未授权的创建、修改或破坏操作
• Availability / 可访问性：确保合法用户可以在需要的时候访问API，不会被阻拦

这三条原则始终很重要，在其他情景中，有一些原则和以上三条一样重要。比如accountability / 可追责(谁做了什么)或者non-repudiation / 抗抵赖(不能否认做过的行为)。我们会在开发实例API时深入讨论安全目标。

安全性可以视作non-functional-requirements (NRFs) / 非功能性需求，并和其他NRF一起考虑，比如性能和可靠性。和其他NRF一样，难以判断安全性目标是否被满足。比如，您很难证明一个安全目标从未被违反，因为这涉及到证明一件否定的事，但是也很难量化什么是“足够好”的保密性。

密码学是实现安全目标的一种手段。我们把安全性视为攻击者和系统之间的一场游戏，攻击者有不同的能力。保密性的标准游戏称为不可分辨性。如图1.4所示，攻击者给系统发送两条等长的信息，A和B，子同选择其中一条，加密后返回。如果攻击者猜出返回的是哪一条则赢。如果所有的工具者猜对的概率都不超过50%，则认为系统是安全的。

图 1.4

并不是所有的场景都像密码学的场景一样精确。这种时候可以把抽象的安全目标定义为具体的、可测试的需求。例如，一个即时消息API可能有一个功能需求，即用户能够阅读他们的消息。为了保持机密性，您可以限制用户只能阅读自己的消息，且用户必须先登录才能阅读消息。这种方法使安全目标成为对现有功能需求的约束。这样就更容易想出测试用例了。例如：

• 创建两个用户并用虚拟消息填充他们的帐户
• 检查第一位用户是否无法阅读第二位用户的消息
• 检查未登录的用户是否无法阅读消息