导读

本文次要基于京东物流的分拣业务平台在生产环境遇到的一些安全类问题，进行定位并采取适合的解决方案进行平安治理，引出对行业内不同业务畛域、不同类型零碎的平安治理计划的探索，最初笔者也基于本人在金融畛域的教训进行了对于API网关治理计划的分享。

写在后面

随着互联网利用的多元化、复杂化、服务化成为显著趋势，越来越多场景中的利用架构采纳利用编程接口（API）作为利用间数据传输和管制流程。同时API接口负责传输数据的数据量以及敏感性也在减少。因而针对API的攻打变得越来越频繁和简单，成为当今不少公司的头等平安威逼。

依据API平安服务提供商Salt Security的最新报告，近66%的企业不足根本API安全策略。在过来的几年工夫里，市场上曾经看到了API面临的危险和攻打的微小增长，不仅呈现了Facebook、T-Mobile等公司的API违规事件，也呈现了美国邮政服务（USPS）和Google+的最新破绽泄露事件。

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

一、背景

2022年2月14日接管到某A分拣核心一线共事反馈：呈现局部解封车无下文的货物在9号至13号之间呈现主动验货状况，经询问该分拣核心场地一线人员均未对其验货。

二、发现问题

2.1 锁定实操报文

查问系统日志，依据运单号JDV0055896869XX定位具体申请报文：

图1 验货实操申请日志

2.2 确定IP

查问nginx日志，定位申请IP：

图2 nginx日志

2.3 确认场地

依据团体自研的运维保障对立治理平台-终端探测性能，根据ip定位出场地起源：

图3 终端探测链路

2.4 定位主机

查看路由信息，依据ip和主机绑定关系，定位主机设施：

图4 路由信息

图5 主机信息

2.5 得出结论

某B分拣核心应用HB-TZFJ-33257A此电脑在2022年2月13日17点55分左右应用脚本工具，假装了HTTP申请报文，将某B分拣核心局部解封车无下文的货物验货至某A分拣核心，形成歹意分拣，使得B分拣核心考核数据转嫁到A分拣核心。

为什么会这样呢？

因为历史倒退起因，分拣pda存在wince和android两个版本，因为wince版本可扩展性较差、设施老本较低等起因，打算逐渐下线wince版本。wince版本没有接入物流网关，调用的传统的rest 服务，这块未对wince设施拜访进行校验拦挡，存在破绽。

最终综合考量将来的推广倒退和整改老本等起因，wince版本不再接入物流网关，只在原有的架构设计上减少一层鉴权拦挡机制，既保证小局部用户平安过渡应用，又节俭了肯定的零碎改变老本。

三、解决过程

基于sha256摘要算法为服务端RestAPI减少鉴权逻辑，避免非法申请。

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

  • registerNo-设施或者是身份识别码
  • signation 序列号
  • siteCode 调用方设施或者是用户所属站点
  • timestamp 工夫戳
  • noceno 随机序列
  • opCode 操作码
  • authorization 签名

registerNo和siteCode 为调用方身份信息，须要事后在分拣管理系统中进行注册获取，客户端基于header中的字段和body信息排序封装，携带salt值做sha256摘要计算，失去摘要后果作为authorization签名信息，和其余字段一起上送给服务端。服务端接管到申请后，基于同样的算法做sha256摘要计算，如果失去的签名信息跟客户端传输的一样即验证通过，否则为非法申请。

之所以采纳这种鉴权计划是因为摘要算法性能较高，满足以后的平安须要，且思考到降级施行的便捷性（目前客户端有很多版本：android和wince设施）最终抉择了此计划。上线鉴权性能后，未携带鉴权逻辑的申请被拦挡，系统安全问题失去很好的解决，并且能够依据日志疾速定位非法申请起源。

四、行业计划鉴析

行业内对于API鉴权的计划有很多种，笔者基于本人的工作教训梳理了以下三类利用场景：

4.1 B-S架构类零碎（网站类）

这类大多以cookie+session或token机制为多，实现一些登录会话等平安治理性能。

4.1.1 cookie+session机制

cookie + session是最传统的API鉴权形式，比方很多网站的登录模块就是靠这种形式实现会话治理。在服务端会生成一个session来保留会话状态，各个session是通过惟一的session\_id来标识的，session\_id会在响应前端申请时返回给前端，前端将其保留在cookie中，后续的所有申请都会携带cookie传到服务器端，服务器端解析cookie后找到对应的session进行判断是哪个客户端发动的。

其长处是：

  • 比拟传统，对开发来说材料较多，语言反对欠缺。
  • 较易于扩大，内部session存储计划曾经十分成熟了（比方Redis）。

毛病是：

  • 性能相于较低：每一个用户通过后端利用认证之后，后端利用都要在服务端做一次记录，以不便用户下次申请的甄别，通常而言session都是保留在内存中，而随着认证用户的增多，服务端的开销会显著增大。
  • 因为基于cookie来进行用户辨认, cookie如果被截获，用户就会很容易受到CSRF攻打；用户如果禁用了浏览器cookie，这套机制就不再实用。
  • 很难跨平台：在挪动利用上 session 和 cookie 很难行通，你无奈与挪动终端共享服务器创立的 session 和 cookie。

总的来说，如果是传统的web网站，且同时认证的人数不是足够大（比方只是外部应用）的都能够用这种形式，很多网站仍旧采纳该形式。

4.1.2 token机制

token令牌机制是用来代替session的鉴权计划，当初很多API的鉴权都是通过token机制。token机制是服务器端生成的一串加密串发放给客户端，客户端申请服务器端所有资源时会带上这个token，由服务器端来校验这个token的合法性。其具备无状态、适宜分布式、扩展性好、性能高和安全性好等长处。

4.2 C-S架构类零碎（客户端-服务器）

这类大多以摘要算法和加密算法的为主。

4.2.1 摘要算法

音讯摘要算法也被称为散列算法或哈希（Hash）算法。任何音讯通过散列函数解决后，都会取得惟一的散列值，这一过程称为 “音讯摘要”，其散列值称为 “数字指纹”，如果其数字指纹统一，就阐明其音讯是统一的。

支流摘要算法有md5和sha系列，sha系列也分为sha1和sha2系列（蕴含 sha-224、sha-256、sha-384 和 sha-512）。md5与sha系列有啥不区别呢？算法外围过程大同小异，输入的摘要信息位数不同，MD5的摘要的长度是128bit，SHA-1摘要长度160bit。多出32bit意味着什么呢？不同明文的碰撞几率升高了2^32 = 324294967296倍，从而进步了安全性，安全性的进步是以就义性能为代价的。

md5把128bit的信息摘要分成A，B，C，D四段（Words），每段32bit，在循环过程中交替运算A，B，C，D，最终组成128bit的摘要后果。

图6 md5计算过程

sha-1算法外围过程大同小异，次要的不同点是把160bit的信息摘要分成了A，B，C，D，E五段。

图7 sha-1计算过程

sha-2系列算法，外围过程更简单一些，把信息摘要分成了A，B，C，D，E，F，G，H八段。

图8 sha-2计算过程

信息摘要越长，产生碰撞的几率就越低，破解的难度就越大。但同时，消耗的性能和占用的空间也就越高。没有最好，依据理论所需性能和安全性做抉择即可。摘要算法因为其单向不可逆性，常常用在验证文件完整性（比方代码的版本比对）和存储系统用户明码口令等场景。

4.2.2 加密算法

加密算法通常分为两大类：“对称式”加密和“非对称式”加密。

对称加密就是加密和解密应用同一个密钥。非对称加密就是加密和解密所应用的不是同一个密钥，通常有两把钥匙，称为“公钥”（Public Key）和“私钥”（Private Key），它们两个必须配对应用，否则不能关上加密文件。

这里的“公钥”是指能够对外颁布的，“私钥”则不能，只能由持有人一个人晓得。它的优越性就在这里，因为对称式加密加解密专用一套密钥，须要将密钥通知对方，一旦传输密钥，不论用什么办法都有可能被他人窃听到。而非对称式的加密办法有两个密钥，且其中的“公钥”是能够公开的，即便泄露也只是泄露一部分数据权限，私钥只有持有人本人保留，数据的权限还是得以管制，这样就很好地防止了因密钥的传输平安问题。

4.3 开放平台（open API）

  1. 安全系数较高的场景（领取、资金下发等）以数字签名为主。
  2. 安全系数不是很高的场景（查问用户信息等）以accessToken机制为主。具体流程为利用须要基于平台调配的AppId和AppSecret 获取一个accessToken（缓存在本地，须要定期刷新），后续申请接口带上accessToken即可，这样对于安全系数没有那么高的接口不须要每次都走加解密的逻辑，进步性能。
4.3.1 数字签名

数字签名是摘要算法与非对称加密算法的综合利用。客户端（申请端）和服务端（接收端）各自持有一对密钥（这外面有两套密钥），各自把本人的公钥给对方，本人持有私钥。申请方先对报文做摘要获取签名信息，而后应用本人的私钥对摘要信息加密（这个过程称之为加签），接管方应用申请方的公钥进行验签，同理接管方解决完业务响应时也是用本人的私钥加签，数据响应给申请方后，申请方也是应用接管方的公钥进行验签。这种算法在开放平台(尤其以微信、支付宝为代表的领取类平台)的API平安设计中较为宽泛应用。

领取开放平台目前支流的两种签名算法：

开放平台签名算法名称规范签名算法名称备注
RSA2sha256WithRSA先应用sha256做摘要，再应用RSA对摘要做非对称加密（强烈推荐应用），强制要求RSA密钥的长度至多为2048
RSAsha1WithRAS先应用sha1做摘要，再应用RSA对摘要做非对称加密（对RSA密钥的长度不限度，举荐应用2048位以上）

数字签名相当于与在性能和安全性做了trade off，因为摘要后果的数据长度是固定的而且效率高，每次对摘要进行非对称加密，性能的损失失去了管制。

五、本身实际经验

5.1 背景介绍

笔者之前始终在金融领取相干业务畛域从事研发工作，参加过2c的钱包app利用、2b的资金下发saas零碎以及资金下发开放平台等相干零碎的API设计与研发工作。上面以资金下发开放平台为例具体谈一下API平安方面的建设。

先说一下何为开放平台：概括来讲就是企业基于本人的业务生态（或者说基于本人的业务sop）进行能力积淀，以API的模式进行凋谢，供第三方开发者（集体或者企业）应用（开发者将能力集成到本人的利用之中，达到赋能的目标），这种行为称之为Open API，提供凋谢API的企业/平台称之为开放平台。

资金下发开放平台是基于薪资下发SOP（规范业务流程）进行能力积淀，以API的模式对外开放，便于企业将薪资下发的能力集成到本人的利用之中，从而具备下发薪资能力。资金下发开放平台整体采纳API GateWay的架构设计。

5.2 API网关整体架构

图9 API GateWay架构设计

API网关采纳pipeline（责任链模式）实现网关的外围解决流程，将每个解决逻辑看成一个pipe，每个pipe解决一件事件。这样无论减少解决逻辑还是减少不同协定的服务，仅需新增一个pipe到调度逻辑，想要禁用某个pipe，也能动态或者动静排除它，即可插拔性。客户端申请过去之后通过pipeline实现鉴权、访问控制、流控以及分流等一系列的前置逻辑。底层容器基于netty实现，对外裸露对立采纳http协定，申请由容器线程池解决，之后散发到利用线程池异步解决。利用线程池在设计之初思考不同类型的工作可能会呈现耗时不一的状况，所以将工作拆分到不同的线程池以做隔离，进步不同类型工作的并发度，从而进步整体的吞吐。

5.3 抉择网关的起因

为什么采纳API GateWay的设计呢？外围有三点思考

1.隔离性

隔离是对企业系统安全的一种爱护，因为API是在边界提供给企业组织之间或企业内部进行拜访的，因而保障企业零碎不受有威逼的拜访是API的首要责任。API网关在平安方面实现了将平安访问控制能力从应用程序中剥离至API网关，实现了平安隔离。

2.解耦性

服务的提供者往往心愿服务具备始终稳固的服务提供能力，因而往往不心愿受到太多的内部性能需要的烦扰，然而业务的疾速倒退决定了业务拜访方的需要是多变的，因而通过在服务提供方与服务拜访方之间设置一个中间层，通过该层封装不同的业务拜访申请并依照对立的服务提供方要求进行转化并拜访。通过这样一个中间层，将两个齐全不同诉求的单方无效的和谐起来，实现解耦。

3.扩展性

从地位与状态上看，API GateWay相似proxy的角色，除了负责申请的接管、路由、响应外，还能够执行诸如流量管制、日志治理、安全控制等。因为业务可能疾速变动，如果外围业务性能无奈在某些方面疾速实现需求，API GateWay能够通过插件化的设计实现自定义性能的疾速扩大，来适应业务灵便多变的需要。

5.4 网关在平安方面的建设

利用接入平台时，须要平台给利用调配appId和appSecret，设置平安规定（加密形式），次要是以摘要算法sha256（加盐）和数字签名sha256WithRsa两种鉴权形式，而后分配资源（接口）权限以及接口限流和白名单等相干的配置。而后接入方依照相应的加密规定进行封装报文申请调试接口，进行接入即可。

具体细节：

  1. ip白名单：ip白名单是指将接口的拜访权限对局部ip进行凋谢，这样就能防止其余ip进行拜访攻打。
  2. 工夫戳：申请报文携带工夫戳跟服务器以后工夫进行比照若超过规定阈值间接被拦挡。
  3. 随机序列：在工夫戳无效范畴内不容许反复，工夫戳+随机序列无效解决了重放问题。
  4. 接口限流：对服务端资源进行爱护。

以sha256WithRsa为例：申请端携带业务字段、appId、随机序列、工夫戳等字段做排序，再做sha256摘要计算，而后应用本人的私钥对摘要后果进行Rsa加密失去sign（这个过程称之为加签），将签名后果和其余字段一起封装传输给服务端。服务端接管到后先对工夫戳、随机序列、ip进行校验，校验通过后应用申请方的公钥进行验签，验签通过后，进行业务流程，业务处理完毕将响应数据做sha256，再应用私钥对摘要数据做Rsa加密失去sign，和业务报文一起响应给申请方，申请方以同样的形式验签解决数据。整个申请-响应的平安流程机制就是这样。

5.5 小结

API网关不仅仅是针对平安方面的解决方案，更多的是对API治理的一种综合解决方案，集安全性、隔离性、可扩展性等多方面的综合考量，是一种企业级API治理的通用解决方案。

写在最初

本文结合实际业务痛点对系统存在的平安危险破绽进行了整改，以及落地验证解决问题，继而对行业平安计划进行比照鉴析，并且联合之前的工作经验探讨了一些对于API平安的架构设计。它可能并不全面，或者说并不齐全实用所有的状况，但本文的意义更多是起到抛砖引玉的成果，启发大家对API平安的思考，唤醒对API平安的意识。

作者：京东物流 魏晓峰

起源：京东云开发者社区 自猿其说Tech 转载请注明起源