API安全生命周期

写在前面

本文的由来主要是最近一年来对内部API风险治理过程中的总结。因为API的种类繁多，并没有写的很详细，但是在其中表达了很多API治理的思路和经验总结。在WAF、黑白盒扫描器、RASP越来越成熟的今天，API导致的逻辑类风险将是各公司面临的最大难题，希望本文可以给予同行者们一些帮助。

一、什么是API

应用编程接口（API）由一组用于集成应用软件和服务的工具、定义和协议组合而成 https://www.redhat.com/zh/topics/api 。设计方式主要遵循SOAP协议或者REST架构。SOAP和REST的关系此处不在赘述，详情可以看https://www.redhat.com/zh/topics/integration/whats-the-difference-between-soap-resth。

API 既可以私有（仅供内部使用），也可以合用（与特定合作伙伴共享以创造更多收益）或公用（允许第三方开发的应用能与您的API 交互，从而推动创新）。

在大多数情况下，企业会采用微服务架构，想要通过加速软件开发来满足需求。基于 HTTP 的 API 已成为微服务架构之间同步交互的首选方法。因为它们可以降低部署、可扩展性和维护的复杂性和开销。这些 API 是将所有微服务连接在一起的粘合剂。API被广泛的应用在各种业务中，也导致大量不规范的API发布到线上，将风险暴露在攻击者的视线中。

二、API生命周期

生命周期就是指一个对象的生老病死。其实所有的非瞬时性的对象都有着自己的生命周期，诞生-存在-消亡。



那结合我们的实际经验，可以总结出API的生命周期，设计-开发-测试-上线-运行-迭代-下线。



三、API安全生命周期

1. API面临的主要网络攻击

在聊API安全生命周期之前，首先我们要思考一下，API会遇到哪些攻击。API作为业务的表达，承载着大量的数据和生产资料，主要的攻击主要包括以下几种：

1. 失陷的访问控制
   “失陷的访问控制”也就是常说的“越权”，荣登OWASP 2021的Top 1。API的访问控制失效，攻击方可直接调用API进行增删改查操作，造成数据泄漏或者生产中断。在有一定安全水位的企业里，越权漏洞一定是高危漏洞种类的重要组成。

2. 数据泄漏(敏感数据暴露、加密失败)
   数据泄漏风险可以说是现在企业面临的最高网络攻击风险了，主要的泄漏途径除了被入侵拖库，就是API的数据过度透出、访问控制缺陷导致被批量调用泄漏数据。随着现在大公司的网络边界安全水位越来越高，被入侵拖库的难度已经非常大了，但是不规范的API暴露的数据泄漏敞口仍然是非常之多。

3. Web网络攻击
   针对API的Web网络攻击主要包括DDoS攻击、注入攻击等等。这类传统web攻击类型作为一类，它们的共同点就是可以通过一定的策略进行拦截。

2. API生命周期中的安全

上面讲的都是外部的网络攻击威胁，但产生这些风险的原因都是内因，我们顺着API生命周期来看每一个环节中缺少的安全部分以及难点。



1. 设计阶段

绝大部分开发同学都想开发出安全和可靠的API，但是在设计之初以及开发过程中，因为自身对风险的整体认知不足，往往很难做到完善可靠的安全设计。在设计阶段，产品、开发等会多次对焦需求和设计方案，但是往往安全的角色在这里是缺席的。

理想情况下，如果每个API的设计阶段都有安全工程师参与其中对其进行威胁建模，那线上的API风险将会大大减少。但是我们都知道，在 安全:开发 = 1:1000 的现状下，人工覆盖每个API的威胁建模将永远是一个美好的想象。

安全部分：

将威胁建模加入到API设计阶段，给出可能发生的风险解决建议和方案。

实施难点：

安全工程师在公司中的人数往往比较少，难以人工覆盖。

实现建议：

建设自动化威胁建模能力，同时对业务进行分层。采用“重点业务人工评审”和“非重点业务自动化威胁建模”相结合的方式，可以有效的对核心高风险接口进行覆盖。在过去半年里，我们在公司内部落地了这个思路，效果非常明显。

2. 开发阶段

开发过程中，安全基本没有机会参与其中，能做的大概就是提供API安全开发规范、安全开发插件、安全辅助包等辅助性安全开发工具。是否使用，全看开发同学的安全意识以及开发项目的紧迫程度。

再一个有用的则是白盒代码扫描，嵌入到CI/CD流程中，发布到测试环境时就进行扫描。但是白盒代码扫描的弊端也很明显，对于逻辑类的风险，目前尚未有很好的检测工具，API是否包含敏感数据也很难判断。

安全部分：

1. API安全开发规范、安全开发插件、安全辅助包
2. 嵌入到CI/CD流程中的白盒代码扫描工具

实施难点：

如何让开发人员将这些安全辅助工具用起来是个挑战，安全意识培养在于一点一滴的积累。

实现建议：

白盒代码扫描实现越权等逻辑类漏洞的检测，在我看来是未来最有可能有效解决逻辑类漏洞的方向之一。但是到现在尚未看到有准确率高、可大规模覆盖使用的产品出现。不过各个公司内部应该都在进行着类似的实现，期待。

3. 测试阶段

如果利用得当，测试阶段将是保证API安全上线的一个关键环节。无论是自动化测试流程还是人工测试，都会对API的业务逻辑实现、稳定性等进行策略，越重要的业务覆盖的越全面。如果在测试的CheckList中加入API相关的内容，则可以接入测试的能力发现API的安全问题。

在这里有一个关键问题，那就是API安全漏洞是否属于bug，例如API的权限校验失效，是否应该算进未被发现的bug数量中。这个共识如果可以达成，那接下来就可以去讨论如何合作了，无论是嵌入到自动化测试平台或者人工测试的CheckList中。在笔者看来，这个共识并不是很难达成，当然这也要看生产关系是怎样的。

安全部分：

与测试团队达成共识，API安全漏洞等于BUG，在此基础上，结合已有的基础设施进行合作，与测试团队共同在上线前发现API的安全风险。

实施难点：

1. 测试团队的工作往往也比较饱和，要想达成共识最好能从上到下进行
2. 测试团队人员的安全专业能力往往欠缺，需要安全团队给予安全能力培训或者提供安全工具辅助发现安全风险

实现建议：

主要还是三个要点：与测试团队达成共识、提供自动化的测试工具以及提高测试同学的安全专业能力。

4. 上线阶段

API发布上线阶段是最关键的环节之一。如果API的漏洞在设计、开发、测试环节中没有被发现，那这将是最后的机会去阻止漏洞产生了，一旦发布到线上，那就只能和攻击者赛跑了。

到这个阶段，理论上传统Web漏洞应该已经都被黑白盒漏洞扫描工具发现出来了，如果还没有，那就很难发现了。但是API权限和API数据相关的漏洞在上线阶段是很容易被安全同学挖掘出来的，不过这里也存在一个人力分配的情况。根据笔者的经验，在这个阶段将有限的安全人力投入到高风险的资产中是最具性价比的。什么样的API是高风险的呢？涉及敏感信息的、涉及资金的、涉及核心基础设施操作的，等等，与设计阶段的评审一样，分层治理。

安全部分：

通过建设自动化发现高风险API能力，例如通过测试流量识别敏感数据API等，对高风险API进行人工安全上线评审，将高危API漏洞拦截在上线前。

实施难点：

主要的难点应该是如何发现高风险的“影子资产”API，在聚光灯的API资产，出现风险的概率往往比较低，但是那些不在我们视线中的API，往往因为没有经过安全评审，产生严重的漏洞。业务、应用越多，“影子资产”API也会越多，如果对API资产进行全面的覆盖、管理，是一个非常有意义且重要的题目。

实现建议：

可以先从流量、日志入手，找到测试环境的流量，通过其识别哪些资产属于高风险资产，“影子资产”API的发现也可以类似的方式持续发现。

5. 运行阶段

运行阶段，API风险往往已经暴露在互联网，随时可能被攻击利用。这个节点的重心要做两件事，API被攻击情况的监控以及API漏洞的持续巡检。

API被攻击情况的监控：例如通过WAF监控阻断SQL注入请求、通过防爬拦截掉尝试利用API越权漏洞获取数据的请求、通过UEBA发现利用自身权限批量获取敏感数据的行为等等。主要的监控能力需要具备WAF拦截、DDoS防御、爬虫拦截、用户异常行为检测等。

安全部分：

通过流量安全监控平台对风险进行检测、阻断，同时结合完善的应急响应流程，对攻击事件进行处置。

实施难点：

1. 数据窃取类流量和真实业务流量相似度较高，通过传统的规则策略发现难度较大
2. 内部人员利用API获取数据的检测难度大

实现建议：

购买或者自研各类监控平台，对高风险API进行重点监控，同时针对各种类型的API风险，制定完善可靠的应急SOP。

6. 迭代阶段

这个阶段可能是最令人头疼的了，即便是这个API上线时经过各种扫描、评审，确定没有安全风险了，后边随着业务需求变化发生改动，就很容易产生新的风险，特别是当开发人员认为前期已经做过非常多的安全检测后，不太可能再出问题时。

安全部分：

1. 需要我们建设响应的API迭代发现能力，当API发生高风险迭代时，介入安全评审流程。

实施难点：

1. 当API发生迭代后，API的名称和API的参数可能并不会发生变化，却在返回值中透出了敏感数据

实现建议：

1. 监控API的返回值，当历史API的返回值中新增敏感数据时，介入安全评审
2. 监控代码仓库变更，当发现API方法代码发生变更时，介入安全评审
3. 监控历史API的名称、入参等，当发生变化时，介入安全评审

7. 下线阶段

大量的API在完成自己的使命后，没有被及时下线，不仅会浪费系统资源，还会变成潜在的线上风险。例如一个API存在越权漏洞，但是因为没有流量一直没有被发现，直到有一天被攻击者利用。

安全部分：

1. 需要我们针对该下线未下线的API建立API生命周期流程管理，催动无流量API下线。

实施难点：

1. 如何识别哪些API是应该下线的，部分API在特殊业务场景下，可能在一年中只会使用几次，这部分要单独维护

实现建议：

1. 监控API的流量变化，对一段时间内无流量的API启动下线流程

3. API中的关键设施

1、API管理

API资产管理平台是API中的关键设施，从上文的API安全生命周期中可以看到，在各个环节都要依赖该平台能力，简单总结大致需要这几点功能：

1. API资产自动发现能力，能否覆盖影子资产是关键
2. API流量监控能力，持续性的对API的总流量及异常流量等各类API数据进行记录
3. API敏感数据识别能力，API会涉及哪些敏感数据
4. API画像构建能力，调用方、调用量等等

API网关在一定程度上也会承载API管理的角色，但是一个公司里，往往不会只有一个API网关，甚至是很多API并没有走API网关，所以从安全的角度，需要有一个all in one的API管理平台。

2、API网关

近几年微服务架构的兴起使得API 网关成为必要的关键设施，庞大的业务系统被拆分成许多粒度更小的微服务，进行独立部署和维护，这种模式带来了更多的跨系统交互，应用API 的规模也爆发增加，API网关已然成为了微服务架构的标配组件。

一个典型的API网关往往承载了非常多的能力，例如路由、限流、版本控制、运行情况监控等，但是在这里只聊安全性。

API网关在安全性中的角色主要是“身份验证”和“访问控制”。API网关的访问控制功能通常从身份验证机制开始，用来确定API调用实际来源。

身份验证方式主要有：

1. API密钥：例如签名等
2. 基础身份验证：账号、密码登录
3. OAuth2.0、OpenID Connect 、SAML等

访问控制主要涉及API的访问控制，哪些用户、调用方可以访问，这里需要和账号体系中的角色进行判断。

3、API权限设计

权限失效类的风险主要包括以下几类：

1. API未授权访问
2. API水平越权
3. API垂直越权

除了上边说的三类权限漏洞，结合业务场景，一般会将权限分为两类

1. API功能性权限/菜单权限（用户有没有权限访问这个功能/菜单）
2. API数据性权限（用户有没有权限访问其它用户的数据）

大多数情况下，只要开发人员有安全意识，往往不会遗漏权限校验。但是往往因为业务紧急情况或者对于架构的错误理解，对权限做出一些错误的理解。当然，还有很多没有安全意识的开发人员，认为有了登录就万事大吉了，这种情况就只能加强安全意识培训了。