API安全治理与防护初探

　　大家好，我是老李。前段时间一直给大家讲API安全，今天看到信息安全与通信保密杂志社发布了一篇关于API安全治理与防护的文章，大受启发，今天特别给大家分享一下，希望能给大家的工作和学习提供一些帮助。
　　随着云原生和软件开源技术的蓬勃发展，越来越多的开发平台和第三方服务快速涌现，应用系统与功能模块的复杂性不断提升，应用开发深度依赖于应用程序接口（Application Programming Interface，API）之间的相互调用。近年来移动应用深入普及，促使社会生产、生活活动从线下转移到了线上，API在其中起到了紧密连接各个元素的作用。为满足各领域移动应用业务需要，API的绝对数量持续增长，通过API传递的数据量也飞速增长。开发框架的演进也是推动API发展的重要因素，随着容器化、微服务的发展，API作为支撑的重要技术也逐步被大规模的使用。
　　API作为连接服务和传输数据的重要通道，已经从简单的接口转变为IT架构的重要组成部分， 成为数字时代的新型基础设施，以及数字化时代一种重要且特殊的数字化资产，随之而来的则是对于API安全问题的思考。本文结合API发展趋势与面临的安全风险，以IAST代码疫苗技术为抓手，深入讨论IAST技术在API安全方面的应用。 一、API安全基础介绍1.1　API发展
　　API是系统不同组成成分的衔接约定，在当下已成为应用间连接服务和传输数据的重要通道，成为数字时代的新型基础设施。
　　API服务的发展历程也可以看做从单体架构走向微服务架构不断变化的过程。随着互联网技术的不断发展，其IT基础设施架构日趋复杂，传统的单体架构已经不适用于当下敏捷的要求。云和容器这两种技术的兴起，为实现企业持续集成和快速部署项目的需求，微服务已成为高速增长公司中构建应用程序的首选。伴随着企业数字化转型，企业应用经历了从内部服务调用到开放平台的场景需求变化，API也经历了从1.0单体架构到2.0 SOA架构再到3.0 REST架构的技术变革，实现通过API输出的资源来完成产品和服务的迭代升级。
　　图1 API发展历程 1.2　API安全挑战加剧
　　根据Akamai的一项统计，API请求已占所有应用请求的83%，预计2024年API请求命中数将达到42万亿次，API承载了应用各组件间数据的流动，成为数据交互最重要的传输方式之一，也因此成为攻击者窃取数据的重点攻击对象，据统计有超过四分之一的组织在没有任何安全策略的情况下运行着基于API的关键应用。根据Salt Security的报告，82%的组织对自己是否了解API资产毫无信心，同时还有22%的组织表示不知道如何发现哪些API存在安全风险，面对API安全威胁不断复杂化、多样化的趋势，政府与企业等的数字化系统正在面临来自多方面严峻的安全挑战。 二、API面临的安全风险2.1　API资产管理混乱
　　云原生等新理念的广泛应用加快了新类型API的开发，API数量呈指数增长。在高速迭代的场景下，企业几乎每天都有新业务需要上线，但未必所有的新业务都经过全面审计，从而很难在第一时间发现和识别这些新的API。同时由于存量API的数量庞大，企业在API管理方面面临许多问题，自身不清楚自身资产拥有多少API、API处于何种状态以及API的更新迭代情况。如若自身API都未进行深层次的梳理清洗，何谈API安全防护。 2.2　API应用安全风险
　　＂缺陷是天生的，漏洞是必然的＂，在系统研发和运行的过程中，API不可避免会产生安全漏洞。开发人员在研发过程中享受技术发展红利的同时，常常忽视了安全的要求，使用的代码或不当的配置引入了安全风险，如OWASP曾在2019年提出针对API的10项常见危险清单，如下表所示，其中有常见的的加密、鉴权等协议问题，同时也包含Web入侵、中间件入侵及数据泄露风险。对比更为熟知的OWASP Top 10, 从API Top 10评级可以看出，传统的Web通用类型漏洞不是API重点关注的风险，权限和资源将是API的主要风险面，这也对API安全厂商提出了更高的要求。
　　2.3　API数据安全风险
　　因性质使然，API会暴露应用程序逻辑、个人身份信息、业务信息等敏感数据，也正因为如此，攻击者逐渐将API当做攻击的首选目标，利用非法控制和使用API接口直接窃取数据等隐蔽而严重的问题进行攻击。
　　通过API可以直接与后端进行通信，如果网络攻击者能够直接访问API层，就相当于绕过了许多安全防护措施，可以直接访问敏感数据，造成许多重大数据泄露事件。
　　2021年：Facebook泄露3.3亿用户数据，包括使用Facebook API的第三方应用程序的数据。
　　2021年：CD Projekt Red游戏公司遭受勒索软件攻击，攻击者窃取了源代码并威胁泄露，该公司的API密钥也被盗。
　　2020年：Twitter遭受大规模安全漏洞，攻击者利用API获取了多位名人和企业的账户，并发布了欺诈性信息。
　　2019年：约8000万Facebook用户的个人资料被盗，攻击者通过利用Facebook API的漏洞获取了这些信息。
　　企业庞大的数据足以勾勒出数以亿计的用户画像，API作为连接服务和传输数据的重要通道，在云原生等新场景下，API安全很大程度决定了数据安全。 三、IAST在API安全领域的关键应用3.1　API资产发现及管理3.1.1　API资产识别
　　传统的API资产发现方式主要通过旁路镜像或主机串联的方式，通过流量分析持续性的捕获传输过程中的API资源并进行自动识别，再结合人工梳理的方式二者形成现有应用的API资产。但传统的方式由于技术原因存在覆盖度不全、框架协议受限等问题，导致难以全面获取API资产，存在未知的＂僵尸＂API、过期API、失效的API参数等。
　　IAST通过插桩的方式天然地适应于多微服务模式，可以在测试阶段将Agent与应用实现融合运行，如何将IAST的工具优势与API的发现能力融合则是技术关键。
　　IAST插桩技术可以从应用中提取相关API资产，自动地分析应用和API中的自有代码，梳理应用中的API资产。在微服务架构下，IAST能够对于同一应用下的API资产进行合并，实时感知API接口访问情况，发现隐藏或废弃的API资产。
　　经过实际场景的不断积淀，现阶段IAST进行资产发现的方式主要有三种：
　　（1）框架动态分析
　　通过插桩在应用运行时环境的探针，从接口实现代码、配置文件等位置，精准识别接口清单、接口签名、请求方法、请求参数等信息。
　　原理则是依赖于应用中已有的标准方法，在程序运行时通过反射读API定义，调取框架中特殊的接口定义方法，通过已有的框架方法获取程序运行中的API资产。
　　例如大家常用的Spring框架，标准的Spring通常将接口写在Controller层，通过分析Controller中的接口既可以获取项目的全部接口。结合字节码插桩技术，获取ApplicationContect初始化完成的源码位置，通过ApplicationContext对象的getBean方法获取RequestMappingHandlerMapping类，最后通过getHandlerMethods（）方法获取所有接口。探针获取后将接口信息封装，发送至Server端进行处理分析，获取API资产的一手数据。
　　（2）Agent获取测试流量
　　通过插桩在应用运行时环境的探针，持续对发送到应用的流量进行监控和分析，进一步梳理应用接口资产清单。
　　（3）特征文件提取
　　此种方式较第二种方式不依赖于已有的功能测试，在系统运行时标准的应用框架中会含有swagger、yapi等接口文件，通过字节码转换能力在应用运行时发现并解析接口文件，从而全量获取API资产。
　　IAST通过在应用的各个服务中部署探针，结合框架动态分析能力从应用中初步获取API资产清单。在功能测试、性能测试等应用运行时环境中，探针持续对发送到应用的流量进行监控和分析，进一步梳理应用API资产清单和进行行为分析，二者相互结合，实现在测试阶段初步梳理应用已有的API资产及使用情况。 3.1.2　API资产管理
　　当前旁路镜像或主机串联等基于流量的API识别可以在测试流量中实时获取应用中已有的API。但随着系统迭代升级，流量方式在持续化获取API的同时存在难以关联应用版本的问题。
　　IAST通过上述方法获取API列表后，根据获取的API的参数名称和类型、接口的函数签名、请求响应、调用情况等基础信息后，根据内置或自定义的API资产分组策略对同类资产进行统一管控。
　　系统版本迭代升级过程中，IAST探针在运行过程中具有Version的版本概念，结合Jenkins和其他CI/CD流程或企业内部的版本定义，自动或手动将Version信息记录在探针参数中。结合IAST探针插桩技术，在应用迭代的过程中记录不同版本的API资产信息，对于同一应用下的API资产进行清洗合并，一方面补充传统API识别方法对于版本概念的缺失，在此基础上可通过版本比较等方式获取最新应用版本的API变动情况，更加细致地进行API资产管理；另一方面实时感知不同版本的API接口访问变动情况，发现因版本更迭带来的隐藏或废弃的API资产，实现僵尸API、影子API的识别发现。 3.1.3　API资产拓扑图
　　IAST通过探针技术直接检测应用中各个API运行情况，在进行功能测试时，结合被动污点分析技术，实现对于外部输入的数据进行全链路追踪，结合API资产获取服务间API调用关系，形成API资产拓扑图，从函数级分析API的关联关系。
　　图2 　资产拓扑示例 3.2　API威胁检测
　　针对API面临的威胁，传统的安全防御并不能完全解决问题，事实证明事后救火并没有真正解决API安全带来的问题。为了解决应用API安全的挑战，降低安全成本，在上线前对API进行全面的安全管控。
　　通过IAST交互式应用安全测试技术将API安全测试前置到开发测试环节，结合已有的功能测试、UI测试、性能测试将安全的能力融合至现有的开发体系中，发现其中可能存在注入类、反射类、通用逻辑类等安全漏洞。 3.3　API数据识别与追踪
　　敏感数据识别是API数据管理中最基础的组成成分，传统流量的方式是分析请求接口的过程中是否从请求或响应中通过正则表达式等匹配方式查看传输过程中是否存在敏感数据。结合API资产情况形成【站点】-【接口】-【敏感数据】的敏感数据拓扑图。
　　但随着微服务架构的不断演进和发展，传统梳理方式获取的资产只是获取接口所涉及的敏感数据情况，并不能很好地实现敏感数据全流程跟踪。
　　通过IAST的插桩方式，一方面可以通过Agent+流量的方式实时发现请求响应、API交互中存在的敏感信息，结合AI自适应引擎提取敏感数据传输过程中的参数、方法特征，获取敏感数据的同时结合企业实际要求实现敏感自动分类分级，另一方面结合污点追踪技术，可实现自定义敏感数据类型、自定义鉴权接口规则、自定义特定方法调用规则等敏感数据识别自定义，实现对任意数据类型的标记和追踪以及企业合规自查。具体实现方法是通过探针在数据传输过程中将识别的内置或自定义敏感数据字段进行标记，追踪敏感数据传播的底层链路，从敏感数据的全生命周期进行追踪，还原敏感信息从输入至存储的完整链路，形成【应用】-【服务】-【接口】-【数据层类型】-【输出/存储】的敏感数据链路追踪图。
　　图3 　敏感信息链路追踪 3.4　API安全防护
　　悬镜首创的基于代码疫苗的智能单探针技术，关键是将智能风险检测和积极防御逻辑注入到运行时的数字化应用中，如同疫苗一般与应用载体融为一体，使其实现对潜在风险的自发现和对未知威胁的自免疫。
　　传统的API资产防护方案一般采用旁路流量分析、威胁情报和WAF进行联动防御，而阻断API漏洞的速度取决于三者联动的速度，所以对于ODay漏洞的发现和阻断效果不佳，往往很难让人满意。因而可以在测试阶段将IAST检测探针部署至应用中，在进行功能测试的同时发现系统中隐藏的API安全风险。当系统通过上线流程进入生产环境后，埋入的IAST检测探针便会自动转变为RASP防御探针，从而将API风险发现能力转化为API安全防护能力。
　　RASP将主动防御能力注入业务应用，借助强大的应用上下文情景分析能力，动态实时发现正在使用、隐藏以及废弃的API资产等，可捕提并防御各种绕过流量检测的攻击方式，提供兼具业务透视和功能解耦的共生主动安全免疫能力，对于ODay漏洞的发现和阻断有很好的效果。结合IAST在测试阶段发现的安全风险，可以采用RASP热补丁的修复方式，将研发过程中存在或未及时修复的API风险进行重点防御，实现IAST检测与RASP防御在API安全层面的联动。
　　此外，RASP还可以通过检测API调用的参数，以及检测API调用的状态持续监控自己的行为，根据内置的敏感数据分析引擎，按照指定部分敏感数据类型或自定义敏感数据特征，在数据传输过程中发现并预警传输过程中可能存在的敏感信息泄露，结合探针的运行态特征，对指定敏感数据进行屏蔽、遮盖、变形处理，从而有效防止敏感数据的泄露，从而保护API免受数据盗窃、恶意输入和行为的影响，实现对API攻击提供主动防御能力。
　　2022年，Gartner发布了《2022云Web应用程序和API防护 魔力象限》，指出目前云Web应用程序和API防护市场正在快速增长。面对API安全需求的激增，通过IAST探针技术在系统上线前完成资产管理、安全检测、敏感数据发现及追踪等安全要求，同时应用悬镜独有的单探针代码疫苗技术，在系统上线后进行API安全防护，从而实现API安全从前置左移到右移的检测与防护全流程覆盖。