写在前面

随着互联网应用的多元化、复杂化、服务化成为显着趋势，越来越多场景的应用架构使用应用程序编程接口（API）作为应用间的数据传输和控制流程。与此同时，API接口传输的数据量和敏感性也在不断增加。因此，针对API的攻击变得越来越频繁和复杂，成为当今许多公司的第一大安全威胁。

根据API安全服务提供商Salt的最新报告，近66%的企业缺乏基本的API安全策略。过去几年，市场上API的风险和攻击大幅增加，不仅有T-等公司的API泄露，还有美国邮政服务（USPS）的最新漏洞和+泄露。

这给我们敲响了警钟：安全无小事，研发需谨慎！

01

背景

了解一下，首先会根据模板缓存状态判断是否需要从网络获取最新的模板。当获取到模板后，就会加载该模板。加载阶段会将产品转换为视图树的结构。转换完成后，将通过表达式引擎解析得到表达式。使用正确的值通过事件解析引擎解析用户自定义事件，完成事件的绑定。完成解析赋值和事件绑定后，渲染视图，最终将目标页面显示在屏幕上。

2022年2月14日，接到A分拣中心一线同事的反馈：9号到13号之间有一些未封口的卡车没有后续货物的自动检查。经询问，分拣中心一线工作人员表示没有检查过。

02

发现问题

了解一下，首先会根据模板缓存状态判断是否需要从网络获取最新的模板。获取模板后，会加载该模板。加载阶段会将产品转换为视图树的结构。转换完成后，将通过表达式引擎解析得到表达式。有了正确的值，事件解析引擎就解析出用户定义的事件，完成了事件的绑定。解析值并绑定事件后，渲染视图，最终将目标页面显示在屏幕上。

2.1 锁定实际操作消息

查询系统日志，根据运单号定位具体请求消息：

图1 检查实际操作请求日志

2.2 确定IP

查询日志，定位请求IP：

图2 日志

2.3 确认场地

基于集团自主研发的运维保障统一管理平台的终端检测功能，基于IP定位站点来源：

图3 终端检测链路

2.4 定位主机

查看路由信息，根据IP与主机的绑定关系定位主机设备：

图4 路由信息

图5 主机信息

2.5 得出结论

某B分拣中心使用HB-TZFJ——该电脑于2022年2月13日17点55分左右，使用脚本工具，对HTTP请求报文进行伪装，在未进行以下货检的情况下，部分解封了某B分拣中心的货物货物到达分拣中心A，构成恶意分拣，导致分拣中心B的评估数据传输到分拣中心A。

为什么会发生这种情况？

由于历史发展的原因，排序pda有两个版本。由于该版本扩展性较差，设备成本较高，计划逐步下线该版本。该版本未连接物流网关，调用传统REST服务。这部分不验证和拦截设备访问，因此存在漏洞。

最终，综合考虑未来推广开发和整改成本后，该版本将不再接入物流网关。只是在原有的架构设计上会增加一个认证和拦截机制，既保证了少数用户的安全过渡，又节省了一定的时间。系统变更成本。

03

解决过程

在服务器端添加基于摘要算法的认证逻辑，防止非法请求。

具体细节：客户端需要在请求头中携带以下字段信息：

为呼叫者的身份信息，需要提前在分拣管理系统中注册并获取。客户端根据字段和body信息进行排序封装，并携带salt值进行汇总计算，得到汇总结果作为签名信息，与其他字段一起上传。发送到服务器。服务器收到请求后，根据相同的算法进行摘要计算。如果获取到的签名信息与客户端发送的签名信息相同，则验证通过，否则为非法请求。

之所以采用这种认证方案，是因为摘要算法性能较高，满足当前的安全需求，并且考虑到升级实施的方便性（目前客户端和设备的版本较多），最终选择了该方案。上线认证功能后，没有认证逻辑的请求被拦截，很好地解决了系统安全问题，并且可以根据日志快速定位非法请求的来源。

04

产业规划分析

业界对于API认证的解决方案有很多。笔者根据自己的工作经验整理了以下三种应用场景：

4.1BS架构体系（网站型）

其中大部分是+或机制，实现一些安全管理功能，例如登录会话。

4.1.1 +机制

+是最传统的API认证方式。例如，很多网站的登录模块就是依靠这种方法来实现会话管理的。服务器会生成一个来保存会话状态。每一个都有唯一标识，在响应前端请求时会返回给前端。前端会将其保存进去，后续的所有请求都会传送到服务器。服务器解析后，找到对应的，确定是哪个客户端发起的。

优点是：

缺点是：

一般来说，如果是传统的Web网站，并且同时认证的人数不够多（例如仅供内部使用），可以使用此方法。许多网站仍然使用这种方法。

4.1.2 机制

令牌机制是一种替代的身份验证方案。现在许多 API 都通过机制进行身份验证。其机制是服务器生成的加密字符串发送到客户端。客户端请求服务器端所有资源时都会带上这个字符串，服务器端会验证这个字符串的有效性。具有无状态、适合分布式、可扩展性好、性能高、安全性好等优点。

4.2CS架构系统（客户端-服务器）

其中大部分基于摘要算法和加密算法。

4.2.1 算法总结

消息摘要算法也称为散列算法或散列算法。任何消息经过哈希函数处理后，都会得到一个唯一的哈希值。这个过程称为“消息摘要”，其哈希值称为“数字指纹”。如果数字指纹一致，则说明消息一致。的。

主流的摘要算法有md5和sha系列。 SHA系列又分为SHA1和SHA2系列（包括SHA-224、SHA-256、SHA-384和SHA-512）。 md5和sha系列有什么区别？算法的核心流程类似，只是输出摘要信息的位数不同。 MD5 摘要的长度是 SHA-1 摘要长度。多余是什么意思？不同明文的碰撞概率降低了2^32=倍，从而提高了安全性。安全性的提高是以牺牲性能为代价的。

md5 将信息摘要分为四段（A、B、C、D）。每个段在循环过程中交替操作A、B、C、D，形成最终的汇总结果。

图6 md5计算流程

sha-1算法的核心流程类似。主要区别在于信息摘要分为五个部分：A、B、C、D、E。

图7 sha-1计算流程

sha-2系列算法的核心流程比较复杂，将信息摘要分为A、B、C、D、E、F、G、H八段。

图8 sha-2计算流程

消息摘要越长，冲突的几率越低，破解的难度也越大。但同时，性能和占用空间也会更高。没有最好的选择，只是根据实际需要的性能和安全性进行选择。由于其单向不可逆性，摘要算法常用于验证文件完整性（如代码版本比较）、存储系统用户密码等场景。

4.2.2 加密算法

加密算法一般分为两大类：“对称”加密和“非对称”加密。

对称加密是指加密和解密使用同一个密钥。非对称加密是指加密和解密使用不同的密钥。通常有两个密钥，称为“公钥”（Key）和“私钥”（Key）。它们必须配对在一起，否则无法打开。加密文件。

这里的“公钥”是指可以向外界公开，而“私钥”则不能，只能由持有者知道。它的优越性就在这里，因为对称加密使用一组共同的密钥进行加密和解密，并且需要将密钥告诉对方。密钥一旦传输出去，无论用什么方法都有可能被别人窃听。非对称加密方法有两个密钥，“公钥”可以公开。即使泄露，也只会泄露部分数据权限。私钥只能由持有者本人保管，数据权限仍可控制。这有效避免了密钥传输安全问题。

4.3 开放平台（开放API）

安全系数高的场景（支付、基金发行等）主要基于数字签名。

安全系数不是很高的场景（查询用户信息等）以机制为主。具体过程是应用程序需要根据平台分配并获取一份（本地缓存，需要定期刷新），然后带到接口上进行后续请求。这样，对于安全系数不那么高的接口，就不需要每次都走一遍加解密逻辑了。提高性能。

4.3.1 数字签名

数字签名是摘要算法和非对称加密算法的综合应用。客户端（请求者）和服务器（接收者）各持有一对密钥（有两组密钥）。每一方将其公钥提供给另一方并持有自己的私钥。请求方首先对消息进行摘要以获得签名信息，然后使用自己的私钥对摘要信息进行加密（这个过程称为签名）。接收方使用请求方的公钥来验证签名。同理，接收方完成处理。业务响应也使用自己的私钥进行签名。数据响应给请求者后，请求者还使用接收者的公钥来验证签名。该算法广泛应用于开放平台（特别是以微信、支付宝为代表的支付平台）的API安全设计中。

目前支付开放平台上主流的签名算法有两种：

开放平台签名算法名称

标准签名算法名称

评论

RSA2

首先用它制作摘要，然后用RSA对摘要进行非对称加密。

（强烈推荐），强制RSA密钥长度至少为2048

RSA

首先使用sha1制作摘要，然后使用RSA对摘要进行非对称加密。

（RSA密钥长度没有限制，建议使用2048位以上）

数字签名在性能和安全性上相当于off，因为摘要结果的数据长度是固定的并且高效。每次摘要都经过非对称加密，性能损失得到控制。

05

自己的实践经验

5.1 背景介绍

笔者之前一直从事金融支付相关业务领域的研发工作，参与过2c钱包App应用、2b资金分配SaaS系统、资金分配开放平台等相关系统的API设计和研发。我们以基金发行开放平台为例，详细讲一下API安全的建设。

先说一下什么是开放平台：简单来说就是企业基于自己的业务生态（或者说基于自己的业务SOP）积累能力，并以API的形式开放给第三方使用开发者（个人或企业）（开发者将能力集成到自己的应用中，达到赋能的目的）。这种行为称为开放API，提供开放API的企业/平台称为开放平台。

基金发行开放平台基于工资发放SOP（标准业务流程）进行能力积累，并以API的形式对外开放，方便企业将工资发放能力集成到自己的应用中，从而拥有发放工资的能力。基金发行开放平台整体采用API架构设计。

5.2 API网关总体架构

图9 API架构设计

API网关采用（责任链模型）来实现网关的核心处理流程，将每个处理逻辑视为一个管道，每个管道处理一件事情。这样，无论添加处理逻辑，还是添加不同协议的服务，只需要在调度逻辑中添加一个管道即可。如果要禁用某个管道，也可以静态或动态排除它，这是可插拔的。客户端请求后，会实现认证、访问控制、流量控制、卸载等一系列前置逻辑。底层容器基于实现，使用HTTP协议对外暴露。请求由容器线程池处理后分发到应用程序线程池进行异步处理。在应用线程池设计之初，我们就考虑到不同类型的任务可能需要不同的时间，因此我们将任务拆分到不同的线程池中进行隔离，提高不同类型任务的并发性，从而提高整体的性能。吞吐量。

5.3 选择网关的理由

为什么采用API设计？有3个核心考虑

1. 隔离

隔离是对企业系统安全的一种保护。由于API是在企业组织之间或企业外部的访问边界提供的，因此确保企业系统不被威胁访问是API的首要责任。在安全方面，API网关实现了应用程序到API网关的安全访问控制能力分离，实现安全隔离。

2、解耦

服务提供商往往希望服务始终具有稳定的服务提供能力，因此往往不希望受到太多外部功能需求的干扰。但业务的快速发展决定了业务访问方的需求是多变的，因此通过服务在提供者和服务访问者之间搭建中间层，通过该中间层对不同的业务访问请求进行封装和转换，并根据以满足统一服务提供商的要求。通过这样一个中间层，可以有效地协调和解耦需求完全不同的两方。

3.扩展性

从位置和形式上来说，类API角色除了负责接收、路由、响应请求之外，还可以执行流程控制、日志管理、安全控制等任务。由于业务可能会快速变化，如果核心业务功能无法快速满足某些方面的需求，API可以通过插件设计实现自定义功能的快速扩展，以适应业务灵活多变的需求。

5.4 网关安全建设

当应用程序访问平台时，平台需要给应用程序分配和设置安全规则（加密方式），主要使用两种认证方式：摘要算法（加盐）和数字签名，然后分配资源（接口）权限和接口电流限制。白名单等相关配置。然后访问方根据相应的加密规则封装报文，请求调试接口访问。

具体细节：

IP白名单：IP白名单是指对部分IP开放接口的访问权限，以避免其他IP的访问攻击。

时间戳：请求消息中携带的时间戳与服务器当前时间进行比较，超过指定阈值则直接拦截。

随机序列：在时间戳的有效范围内不允许重复。时间戳+随机序列有效解决了重放问题。

接口限流：保护服务器资源。

以此为例：请求端携带业务字段、随机序列、时间戳等字段进行排序，然后进行汇总计算，然后使用自己的私钥对汇总结果进行RSA加密以获得签名（此过程称为签名），然后将签名结果与其他字段一起封装并传输到服务器。服务器收到后，首先验证时间戳、随机序列和IP。验证通过后，使用请求者的公钥来验证签名。签名验证通过后，进行业务流程。业务处理完成后，对响应数据进行处理，然后使用私钥对汇总数据进行RSA加密得到签名，并与业务消息一起响应给请求者。请求者验证签名并以相同的方式处理数据。这就是整个请求-响应安全流程机制。

5.5 总结

API网关不仅是一个安全解决方案，更是一个API治理的综合解决方案。它将安全性、隔离性、可扩展性等方面综合考虑到企业级API治理中。通用解决方案。

写在最后

本文结合实际业务痛点对系统中的安全风险漏洞进行整改，并实施验证解决问题，然后对行业安全解决方案进行比较分析，并根据以往的工作经验讨论一些API安全相关的架构设计。可能并不全面，也可能不能完全适用于所有情况，但本文的意义更多的是启发人们对API安全的思考，唤醒API安全意识。