刘顺，网络安全专家、网安加社区特聘专家、诸子云百家智库安全专家、CSA云安全联盟专家、TTSP智库安全专家。12年网络安全从业经验，曾就职于汽车制造、互联网、科技等类型企业，担任安全负责人、资深安全工程师、高级安全架构师等职位；主导过企业安全治理规划、安全团队建设、企业安全体系建设、应用安全体系建设、数据安全与隐私保护建设、终端安全管控建设、安全防御项目建设、安全运营监控建设、物联网安全服务建设、网络安全司法预防与追责项目建设等众多领域的安全项目；在网络安全与隐私保护方面具有丰富的管理与实践经验。

　　许理想，安全工程师，具有甲乙双方安全工作经验，擅长漏洞挖掘、代码审计；在红蓝对抗、渗透测试、数据安全等领域具有丰富经验。

　　API是企业推进数字化转型的重要基础设施和技术支撑，随着企业数字化转型的发展，很多企业从以往内部消费企业的系统、产品和功能，到如今通过开放平台等各种方式，将自己的系统能力通过API提供给不同的第三方。Gartner预测到，API将成为企业Web应用程序中最常见的数据泄露攻击媒介。原本在内网使用的应用系统还可以依赖局域网的安全防护，但随着“开放API”的发展，企业网络边界逐渐模糊，其原有基于内网的防护措施已无法满足面向互联网的安全需求，暴露在互联网上的各种API接口扩大了企业的风险暴露面。针对企业API的攻击正成为黑灰产的首选，相较于传统窗体和Web网页，API承载的数据价值更大、攻击成本更低，通过攻击API来获取高价值数据、进行业务欺诈成为越来越多非法分子的常规手段。

　　近日，创新安全服务商Salt Labs发布了2023年第一季度《API安全态势研究报告》（以下简称《报告》）。《报告》数据显示，94%的受访企业在过去一年经历过生产系统中的API安全问题，17%的受访者表示他们所在的企业组织由于API安全漏洞而发生了数据泄露。《报告》还发现，在过去的6个月时间里，API攻击活动数量快速增长了400%，其中有78%的攻击发生在经过初步安全性验证的API上。研究人员表示，API威胁态势仍在持续加剧，其安全性将在2023年成为企业组织安全运营团队关注的重点。

　　某安全实验室对48家银行的线上信用卡业务接口（API）进行安全评估，发现其中有38家银行的API存在安全缺陷，20家银行信用卡API接口存在未授权访问等高风险缺陷。通过对捕获到的攻击情报进行分析发现，至少有８家银行的信用卡业务已经遭受到了黑灰产发起的恶意攻击。

　　Apache APISIX接口未授权访问漏洞、某微博用户查询接口被恶意调用、某电商接口非授权使用等API安全事件频发，这些与API相关的安全事件不得不引起我们对API安全的重视，API安全治理刻不容缓。

　　本文以下章节将分别介绍API基础知识、API安全挑战、API总体安全能力以及API安全框架。

　　API是Application Programming Interface的简写，它是实现其他软件组件之间交互的桥梁。它通过定义函数、协议，将WEB应用、操作系统、数据库的能力以接口的方式提供给外部使用，使用者不需要知道接口的实现逻辑，只需要提供接口所需信息就能获取到想要的结果。

　　RESTful API是REST风格的API，REST是一种架构风格，是现在HTTP中最主流的API设计规范，这种规范的设计原则包括：

　　首先要先介绍什么是资源，资源指的是网络上的一个实体，如一张图片、一个用户信息等。在RESTful架构中，每个网址代表一种资源，并且只用名词来表示该资源，比如有一个API提供学校的信息，包括学生信息、老师信息，则它的路径可能会显示：

　　使用HTTP动词（GET、POST、PUT、DELETE）表示对资源的具体操作，该类操作对应数据库中的增删改查。

　　SOAP API是简单对象访问协议（SOAP）。它是由万维网联盟及其成员编辑定义的消息传递标准。它定义了用XML和HTTP访问服务、对象和服务器的方法，是一个将不同类型的软件组件连接起来的协议。

　　SOAP消息的根元素，把xml文档定义为soap消息，这个元素有一个namespace属性，这个决定当前SOAP报文所使用的规则，这个规则是依赖于SOAP版本的。通过查看官网文档，SOAP1.2使用，SOAP1.1使用。

　　该组件为可选部分。包含有关SOAP消息应用程序专用信息，通过SOAP模块可将SOAP扩展。

　　当SOAP API调用失败时，可在该标签内显示错误信息。该标签存在以下几个子元素：

　　SOAP为了保护数据包的完整性和保密性，SOAP可以通过设置WS-Security模块，对SOAP进行XML加密和签名，支持端到端的安全性。

　　RPC API是一种允许在不同上下文中远程执行函数的规范。通俗来讲就是客户端可以在不知道调用细节的情况下，调用存在于远程系统上的某个对象。RPC有以下特点：

　　RPC是一种协议，那么就会有依照这个协议的规范实现框架，如：Dubbo、GRPC等。

　　因为需要远程调用，那么需要在网络中传输数据，RPC没有对网络传输协议做限制，只要满足数据传输要求的都可以使用。比如dubbo框架支持很多的传输协议，包括：rmi协议、hessian协议、http协议。

　　调用方不清楚远程服务器应用使用的开发语言，所以需要兼容用不同语言开发的应用程序，因此RPC需要有跨语言能力。

　　客户端调用一个远程的过程，将参数和附加信息序列化为消息，然后将消息发送到服务器端。服务器端在接收到消息后，将信息的内容反序列化，执行所请求的操作，然后将结果发送回客户端。客户端和服务端各自负责参数的序列化和反序列化。下面是RPC过程调用的流程图：

　　To C-API（面向个人用户）、To B-API（面向企业）、To G-API（面向政务），企业有哪些类型的API，有多少个API，有多少对外开放的API，有多少API包含敏感数据，各API分别采集共享了哪些类型和等级的数据，API的使用频率怎样，是否存在长期未使用的僵尸API。企业如果没有API资产测绘能力，理不清API资产，上述问题是未知的，直接影响对API的安全管控效果。

　　一是未对API的访问请求进行认证，此类问题由多种原因产生，比如API设计之初的定位是向内网其他应用系统提供服务，因此未考虑对调用方进行身份认证，某天因为新的需求要将API开放给外部用户使用，直接使用已存在的API，不会再额外考虑增加认证机制。

　　二是未对API接口进行访问频率的限制，当接口存在越权漏洞可获取敏感信息时，攻击者通过遍历接口造成大量敏感数据泄露。

　　三是未对爬虫类行为进行限制，攻击者利用大量的动态代理IP，低频慢速的方式来绕过现有的防御措施，利用网络爬虫爬取账号权限以及开放在公网上的API接口数据，导致数据泄露。

　　API在设计之初未考虑用户群体及具体的使用场景，身份认证设计存在不足或者缺失，导致攻击者可以进行未授权或者越权攻击，可以通过API任意访问访问数据，例如：Kubernetes的8080端口、Docker的2375端口的未授权访问等。身份认证鉴别机制不强，也会存在被暴力破解、撞库、社会工程学攻击等风险。

　　SQL注入、代码注入以及命令注入这些注入型的漏洞危害性极高，可能导致的后果包括但不限于敏感信息泄漏、服务器沦陷，一旦被利用给企业带来的损失无可估量。

　　API接口未对用户或者访问IP进行速率限制时，攻击者可持续高频地使用多个虚假用户或者IP对API进行访问，从而严重消耗服务器资源，导致其他正常用户无法访问相关接口。

　　应用开发过程会引入开源或第三方插件、模块、框架等，当引入的开源模块、插件存在漏洞时，会导致代码中的漏洞、后门、恶意代码安全隐患引入到API接口中。

　　基于HTTP协议的API，使用传统的WEB防护手段可以起到一定的防御作用，但是API的安全防护需要额外关注身份认证、访问控制、数据安全、爬虫以及行为审计。

　　近年来API数据泄露事件屡见不鲜，API连接交互中涉及到了个人数据和业务数据多种类型，同时数据调用可能涉及多个服务提供、场景建设、交易发起等主体，意味着数据泄露和欺诈风险点增多，任何一方数据保护存在薄弱环节都可能危及数据安全，如不法分子可能非法获取客户信息，第三方金融供应链的应用方可能暗箱违规套取交易信息，导致敏感数据泄漏等。

　　API承载着不同类型的业务服务，黑灰产利用API防护能力的不足，可导致一系列的业务安全问题，包括：营销作弊、撞库、扫号、盗号、刷量、抢单、积分套现、广告引流等。

　　未建立黑灰产攻击链路情报，对黑灰产组织结构、活跃社区、攻击资源、攻击手法以及套利变现方式不了解，风险IP、风险画像、数据泄露情报缺失，无法与现有的网络安全防护设备、风控系统有效联动，API主动防御能力差。

　　API审计监控机制的缺失，将导致无法及时检测到异常的大量数据下载行为、网络爬虫行为、越权访问行为、高频访问等行为，风险不可见，发生安全事件后无法及时处置。

　　API资产发现、风险检测、数据安全管控等能力缺失，API安全管理规范缺失，未基于API生命周期建立完善的安全管控机制，API管理不健全。

　　OWASP在2019年发布了OWASP API Top 10 2019版本，OWASP计划在2023年10月份发布最新的OWASP API Top 10 2023版本。如果API应用在设计之初没有考虑这些安全缺陷，那么攻击者利用安全漏洞会造成企业、客户信息泄露，并使企业承受经济损失。以下将介绍OWASP API Security Top 10 2019版本中常见漏洞的原理及案例。

　　对象级别授权是一种通过代码实现的访问控制机制，当这种控制机制失败时，攻击者可以在发送请求中改变对象的ID，导致未经授权的信息泄露、修改或破坏所有数据。这类问题在基于API的应用中非常普遍，因为服务器通常不会完整地跟踪用户的状态，而是依赖用户请求参数中的对象ID来决定访问哪些目标对象。比如常见的订单查询，只会对传入的订单号进行信息查询，而不会判断该订单号是否属于当前用户，从而造成越权漏洞。

　　身份验证机制的实现往往不严格或者安全方案考虑不完整，使得攻击者能够破坏身份验证令牌，或利用漏洞临时或永久地盗用其他用户的身份，破坏了系统识别客户端/用户的能力，损害API的整体安全性。该类风险可能出现的场景包括：应用系统没有验证码校验或者没有用户锁定功能，导致攻击者对同一个用户进行暴力破解；系统允许弱密码；在url中包含有敏感认证信息，如认证token、账户密码等；使用jwt认证框架，允许签名方法为空，导致攻击者可以任意伪造token信息等。

　　系统登录界面没有图形验证码和登录失败次数限制，攻击者可以通过收集到的字典，对系统进行暴力破解，如果存在弱口令会导致系统权限的丢失。

　　应用系统没有对返回数据字段采用最小化原则，直接将实体对象返回，会导致敏感信息泄露。

　　某用户信息接口，查询时会返回该用户的所有信息，经了解应用直接将user对象转成json直接返回到前端，导致用户账号密码、手机、身份证等敏感信息都泄露了。如果接口还存在越权漏洞的话，那么攻击者可以通过遍历拖走大量的用户数据。

　　处理每个API请求会消耗应用服务器的网络、CPU、内存、存储空间等资源。如果应用没有对请求的超时时间、请求包大小、请求频率、查询返回的页数等进行限制，可能会导致DOS攻击、接口遍历、暴力破解等漏洞。

　　例如，，这个请求中加载的JavaScript文件是jquery-ui-core和editor。由于在script-loader.php文件中定义的181个JavaScript文件都可以被加载在单个请求中，恶意攻击者在无需授权登录的情况下可以发送大量请求，导致服务器负载增加，从而实现拒绝服务攻击的效果。

　　应用系统如果存在某些API接口，攻击者通过发送正常的报文，如将请求中校验角色身份的字段改成管理员或某些接口只提供给管理员使用，但是应用没有对接口进行有效的权限限制，普通用户也能访问，那么就会导致这类问题，造成权限缺失。

　　可成功添加用户并将该用户赋予为超级用户，新建的用户可成功登陆并为最高权限。

　　如今WEB框架，像Spring MVC，可以将传入的参数映射为实体，通常一个实体会包含着很多的字段，如User实体会包含有用户姓名、年龄、身份证号码、账号、账号密码等字段。如果应用修改用户信息的接口原目的是只允许修改用户手机号、年龄信息，但开发为了方便直接将实体作为变量传到SQL语句中，如果用户传入包含账号密码字段，因框架会将该字段映射到实体，然后传给SQL语句，导致更新了用户的账号密码。

　　如果开发或者运维人员不安全的配置中间件、应用系统，就可能会导致预料之外的安全风险。如应用没有禁用多余的HTTP动词：DETELE、PUT，比较经典的漏洞就是iis的webdav配置不当，可通过PUT上传任意文件;跨域资源共享CORS头配置不当，导致资源控制缺失；Tomcat管理后台未设置访问白名单，攻击者可通过爆破登录接口的方式登录后台，上传恶意war包控制应用服务器；nginx规则配置不当导致的任意文件读取问题。

　　Tomcat配置不当，管理员账号为弱口令，导致通过暴力破解进入管理后台，上传war包：

　　该漏洞是因为应用系统过分信任用户输入，没有对用户的输入进行校验，直接将输入插入到应用系统的查询或命令中，应用程序将用户的输入当作正常执行的一部分，如果输入中包含着一些恶意payload，攻击者可以改变应用程序原来执行的逻辑，从而导致系统产生非预期的结果。例如：在SQL注入攻击中，攻击者注入数据来操纵SQL语句，获取数据库中的敏感信息。

　　在查询接口处输入单引号，发现后端返回错误信息，提示语法错误。依据个人经验可以知道该查询是存在SQL注入的。

　　一个API通常有许多不同的版本、功能、端点和许多影响该端点行为的参数。这一块实际就是API资产管理不当的问题，如：历史接口未做下线处理、测试地址暴露等。通常这些问题都是由于API资产信息记录不全、不准确，一般这些未记录的接口都是安全防护较为薄弱，攻击者可通过这些接口实现更进一步的攻击。

　　应用系统缺乏对API的访问记录和攻击日志做日志记录，在未被监测的情况下滥用系统和攻击系统。一个安全的应用系统是需要日志和监视，当发生安全事件事件时，可以依据日志信息跟踪可疑活动并及时响应攻击。

　　该风险类我们举一个正向的例子，展示系统如果有完善日志记录，会对溯源有很大的帮助。

　　应用管理员在应用服务器上使用后门工具进行扫描，发现存在后门，通过文件创建时间排查相关的应用访问日志：

　　通过OWASP API Top10安全风险的分析可以看到，API安全和传统的Web安全有区别也有联系。一方面需要在设计和开发阶段，对API的安全性进行良好的构建和设计；另一方面还需要在进入运维阶段后，针对API进行专项型的防护，根据API的特点构建全生命周期的防护体系，从而更好地应对各类风险，做到未雨绸缪、防患于未然。

　　美国国家标准与技术研究院（简称NIST）于2018年发布《提升关键基础设施网络安全的框架》（以下简称CSF）。NIST CSF由框架核心、框架实施层和框架轮廓三部分组成，其框架核心包括五个功能，即风险识别能力（Identify）、安全防御能力（Protect）、安全检测能力（Detect）、安全响应能力（Respond）和安全恢复能力（Recover）。

　　该能力框架实现了网络安全“事前、事中、事后”的全过程覆盖，帮助企业主动识别、预防、发现、响应安全风险。目前该框架已成为全球认可的安全评估体系。参考NIST CSF网络安全框架，以下分别从API资产识别能力、API安全防护能力、API安全监测能力、API安全运营管理能力四个方面介绍API安全应具备的能力。

　　API安全最重要的一项工作就是API资产的识别发现，毕竟如果不知道要保护的目标何谈如何实施保护。在复杂多变的系统环境中自动发现公开的、私有的、面向合作伙伴的所有API，并识别API安全暴露面，建立API清单，对API进行分类分级。这要求企业要能够根据API的业务场景、出站数据的敏感度、风险等级等信息对API进行分级分类，完善企业“API清单”。只有对API有全面的了解，才能避免安全管理盲区，降低API的数据泄露和合规风险。

　　数据安全是当前监管和企业特别关注的话题，API承载着海量数据的流转、交互。企业应进行数据分级分类治理，并通过技术手段对通过API进出的数据进行持续监测评估，自动梳理API接口中的敏感数据流，生成API接口与敏感数据映射，确保个人隐私数据、商业数据以及其他敏感数据进行持续监控。

　　随着攻击面的变化及攻击者手段的隐秘多变，企业应建设持续挖掘、收集API相关漏洞的能力和机制。如：定期对应用代码进行安全专项审计，审计工作可通过人工或工具自动化方式开展，利用入侵&攻击模拟能力（BAS），评估企业安全技术有效性。

　　现在的API大多数是被“组装”出来，不是被“开发”出来的。无论是企业自己开发，还是外包给供应商开发，开发出来的软件其源代码基本上都是混源代码，即由自主开发的源代码和开源软件代码共同组成。开源第三方组件作为软件开发最基础的原材料，位于软件开发供应链的源头，开源安全会直接影响最终软件的安全性。API安全治理应对第三方组件进行安全性验证，并持续关注相关平台的信息披露和更新情况，适时更新相关组件。

　　企业应用应能按应用方、用户、接口等维度，依据最小授权原则进行API授权，对于未授权的资源禁止访问。

　　API应根据调用对方，按最小化原则进行严格的访问控制，防止API被非法使用，或通过API越权访问。

　　企业应对API请求执行一定的限流策略，考虑到系统的处理能力，需要对API请求做一定的限流防护。此类场景可以用于缓解基于API的DDoS攻击，有效防止资源消耗在无意义或恶意的API请求上。

　　所有的第三方输入都是不可信的，API应具备对第三方请求提交内容进行校验的能力，防止请求中包含不安全内容。

　　除网络层传输加密外，API应具备统一的报文加解密能力，以确保报文数据的保密性。

　　企业无需展示明文数据时，可对API访问的敏感数据进行脱密，例如身份证号、部分姓名，银行卡号、交易号等，以减少敏感信息的泄漏风险。

　　API应具备防重放能力，防止攻击者通过非法手段获取报文后，重复请求API。

　　企业可通过在线威胁情报平台，实现对异常账号、手机、ip等存在高频访问行为、异常数量级数据访问行为、异常时间访问等异常行为时，做到检测并和拦截。

　　企业不仅需要使用WAF等网络安全设备对API的访问行为进行检测，同时应对API请求与返回报文进行识别，从而检测是否存在SQL注入、XML注入等攻击行为。

　　API已经变成数据泄露的重要渠道，企业需要对API的访问行为进行检测，包括访问来源、访问的API接口、访问的数据类型、访问数据的敏感级别、访问数据量等等，形成API行为基线特征，构建异常访问行为规则，持续进行数据安全异常检测。

　　为了管理API的使用，可以限制用户在特定时间段内进行的API调用次数和API配额。可使用节流计数器节流，当传入的客户端请求满足特定条件时，计数器会增加。API配额根据限制设置，确定在设定时间内可进行的最大调用次数。如达到API配额，则不允许来自该特定客户端的流量。

　　企业应梳理和制定安全规范包括内部系统集成、外部系统集成的整套集成安全规范体系等，形成开发者、服务提供方、运营管理员的整体一体化流程和制度。

　　企业应构建威胁分析与处置能力，需要具备将所有威胁日志转发至统一的大数据分析平台，结合业务与应用部门的数据，实现对所有API的统一监控与威胁事件感知，以达到可快速处置威胁事件的目的。

　　企业应具备在攻击或窃密事件发生前具备预警能力，进而提前预防、及时响应。可从业务流量中细化攻击的行为结合攻击者历史情报信息对攻击者的资源、手法、意图、团伙情况、潜在目标进行关联跟踪分析，进而构建攻击者情报库，对攻击者进行持续跟踪。

　　为满足上述API安全能力，企业可通过构建API平台，将各安全模块进行整合，实现内外部各业务系统之间的交互，解决系统之间的安全问题，提高系统管控水平、安全能力，最终促进企业API安全发展。

　　API平台能力概括为API威胁情报（黑产/溯源）、攻击防护、API接口梳理和监控、API访问策略管理与控制、API数据安全防护(API数据泄露检测、数据动态、脱敏防护)。实现这些要是通过API安全网关、API管控平台两个关键模块，二者相辅相成共同构建API安全核心能力平台。

　　除此之外，结合内部基础设施、API安全体系，从应用、网络、管理三个层面实现防御能力的落地嵌入，最终构建出符合企业API安全架构模型。整体架构图如下：

　　API网关是随着微服务概念兴起的一种架构模式。原本一个庞大的单体应用业务系统被拆分成许多微服务系统进行独立的维护和部署，服务拆分带来的变化是API的规模成倍增长，API的管理难度也在日益增加，使用API网关发布和管理API逐渐成为一种趋势。一般来说，API网关是运行于外部请求与内部服务之间的一个流量入口，API网关在一定程度上也会承载API管理的角色，因此可以在API网关中统一集成一些应用安全防护能力，如：XSS、SQL注入、加解密、数据脱敏、权限控制等。

　　大多数项目采用网关的解决方案的最主要的原因。给出了访问后端API的所有客户端的单一入口，并隐藏内部服务部署的细节。

　　上游服务对本服务请求QPS超过阙值时，通过一定的策略(如延迟处理、拒绝处理)对上游服务的请求量进行限制，以保证本服务不被压垮，从而持续提供稳定服务。

　　在进一步转发之前，能够在转发之前转换请求和响应（包括Header和Body），如将普通的http请求转为内部的服务化请求。

　　为了保护系统的可用性，在分布式系统中避免后端服务不可用时消费者重复调用服务，加重整个系统服务的负担，导致系统性能下降，网关可对后端不可能用的服务暂时停止，当服务正常时，重新开启对应的链路，这种方式称为熔断。降级是指当自身服务压力增大时，采取一些手段，增强自身服务的处理能力，以保障服务的持续可用。比如，下线非核心服务以保证核心服务的稳定、降低实时性、降低数据一致性。

　　减少网络带宽和往返时间消耗，如果可以缓存频繁要求的数据，则可以提高性能和响应时间。

　　网关应该能够成功进行身份验证并仅允许可信客户端访问API，并且还能够使用类似RBAC等方式来授权。

　　防止攻击者频繁请求API，导致资源耗尽无法正常响应，与流量控制类似，不过该处是对恶意用户、ip等维度做拦截，而流量控制是对服务、接口层级做拦截。

　　通过对比各开源网关，综合所有网关基础能力和安全能力，结合API运行过程实际所需功能，最终生成API安全网关能力图如下：

　　网关内部定义不同协议的转换规则，接入方可使用不同协议进行接口调用，请求进入到网关时，查询接口对应的后端服务，自动转换为内部报文格式。

　　支持多种认证方式，可根据用户、应用需求，通过不同方式实现身份认证和鉴权。

　　限制接口固定时间内的访问频率，降低接口被恶意利用的风险。发生安全事件时，可通过全链路日志排查事件整体过程，实现快速应急。

　　可防护后端应用免受安全攻击，如DDOS攻击、XSS攻击、SQL注入等。完整日志信息收集，可在需要进行安全审计时提供证明。

　　结合威胁情报平台，基于情报构建API行为基线，对存在风险的ip、账号进行自动封禁或自动告警。

　　管理平台集中管控API的上下线，可查询全部API异常日志，展示API调用链路。

　　随着现代应用程序开发从单一架构转向微服务架构，API使用率将继续稳步增长。随着越来越多的数字化应用崛起，API上所承载的数据安全问题也逐渐暴露，API安全将很大程度决定企业当下整体的安全性。同时，API安全绝非易事，本文从API面临的安全风险、挑战，描述了API应具备的总体安全能力，最后通过API安全网关及API安全管控平台介绍了如何实现API安全能力。API全生命周期安全管理要求，还涉及API开发、API测试、API发布、API运维、API迭代、API下线六个阶段构成（如下图所示），可参考信通院《应用程序接口全生命周期安全管理要求》，在每个阶段分别建立相应的安全能力。