API应用现状

在云原生技术快速发展的当下，云计算、容器、微服务、K8S这些词汇不断地映入大家的眼帘，可同样频繁出现在大家视野中的，还有着越来越多的网络攻击事件，如近几年比较常见的勒索病毒事件，少则几千、多则几十上百万的“赎金”让众多企业和个人也是极为烦恼。随着微服务架构的流行，API的使用变得越来越普遍，根据数据显示，当前整个Web系统有超过83%的流量都是通过API来访问的。与此同时，超过44%的企业正在建造和维护100个或更多的API，API流量正在以极快的速度增长。那API的大量应用是否会带来安全问题呢？API风险在传统IT架构和云原生架构下又有何不同呢？本篇文章，探真小何就来带大家了解云原生环境下的典型安全风险—API安全。

API风险介绍

API（Application Programming Interface）作为程序之间进行数据交互的通道，一直扮演着极为重要的角色，现代应用的开发，往往都会预留众多定义好的接口，以此来提高程序的扩展性与兼容性，尤其在微服务架构下，各个应用都被极尽可能的细分，因此它们彼此间更需要API来进行数据交互，但同时也产生一个问题，那就是API数量爆发式的增长。物理学告诉我们，数量变大容易引发熵增，熵增则代表了混乱程度加大。而API数量的激增，就在带来众多便利的同时，引发了严重的安全问题，那么API带来的安全风险有哪些呢？根据OWASP API Security Project 所总结的API排名前十的API安全风险分别是：无效对象级授权、无效用户身份验证、过度数据暴露、缺乏资源和评级限制、无效功能级授权、批量分配 、安全错误配置、注入、资产管理不当、日志记录及监控不足，具体可参照下表。

K8s-ServerAPI未授权漏洞检测工具

以下，我们就用两个例子，来展示一下API带来的安全风险：

例1：南北向API安全风险—未授权访问带来的灾难

K8s作为基础组件之一，在整个云原生体系下扮演着极为重要的角色，就如同我们人体的大脑一样，指挥着全身上下各个微服务的运转和交互，而k8s 中的API Server，则是各个模块间的通信枢纽，k8s API Server提供了k8s各类资源对象（可类比人体各个器官）的增删改查及watch等HTTP Rest接口。简单来说，k8s API Server让我们可以通过接口的方式操纵整个集群。一个普通的k8s server api长这样，我们可以通过api获取各种集群相关信息以及进行交互操作：

按理说，这么重要的接口，不应该对外开放才对，但实际上很多运维人员会为了方便或因为一些误操作将其暴露在公网之上。我们通过某安全搜索引擎搜索发现，仅一个关键字，全球2000+的k8s集群便如此“坦诚相见”。

随意尝试连接测试后发现，命中率基本在90%以上，下图便是受影响的k8s集群之一：

如此，我们可以通过远程连接完全接管集群，做任何想做的事，可谓“小手一抖，集群到手”。这样简单的提权方式，对黑产来说可真是个好消息，试想如果把这些集群全部加密勒索或者用于挖矿的话，那后果将是灾难性的。

例2：东西向API安全风险—横向注入导致的集体沦陷

试想，如果让你搭建一个web系统你会怎么办呢？可能很多自己做过网站的同学会说：开源代码+apache+mysql三连，就完事儿了。的确，在当下搭建网站已经是一件轻而易举的事，不过还存在一个问题：作为网站的搭建者，大家会把这几样东西放在同一台服务器，还是分开部署(类似微服务架构)？这时候大家就有不同的意见了，可能有的会放在一起，有的会分开。我们先来说放在一起的情况，如果当前该网站系统同时存在SQL注入与Apache远程命令执行漏洞，那攻击者可能的攻击路径是什么呢？如下图所示，黑客可通过API注入控制Mysql，再通过提权来达到控制服务器的目的，或者直接通过Apache远程命令执行控制服务器，这样，我们无论通过哪种漏洞，都是拿到了当下这一台服务器的权限。

而在微服务架构下，又会是怎样的方式呢？从下图可以看到，在这个K8s集群当中，我们拥有两个Node(两台服务器)，而每个Node中，可能存在多个pod，这些pod内则运行着不同的服务。当我们搭建一个web网站的时候，会分别为apache服务和mysql服务创建不同的pod，由于k8s的机制，这些pod会被随机分布在Node中，这样就可能出现下面图中的情况，不同的服务位于不同的节点。此时攻击者利用这两个漏洞进行攻击时，他获取的权限也就位于两台服务器上，也就是说，黑客可以通过攻击一个web服务，同时控制两台服务器，而造成这个问题的原因，就是两台服务器之间API的相互调用所导致的。

同上原理，在我们的实际应用中，也存在大量这样的横向API调用情况，包括k8s自身的很多组件，同样有不少的API相互调用，而这也为我们的内网安全带来了更大的风险。

API安全防御

那么如何来防御API风险呢？根据API所面临的安全威胁场景，我们通常可以从如下几个方面制定防御策略。

（1）传统漏洞防御

该项主要是针对一些传统的安全漏洞进行防护检测，比如sql注入、xss、rce、文件包含等等，通过安全的架构设计及编码能够防御一部分该类风险，此外，借助WAF等外部安全产品也是一种不错的选择。

（2）数据校验

数据的合法性校验一般是针对数据的长度、类型等进行检查，如果传入的数据不满足接口规范，则不予处理，不同的接口可能有不同的规范，需要针对性校验。

（3）数据加密签名

在接口调用数据传输中，为防止中间人攻击和篡改，针对敏感程度不高的接口，可通过加密算法对数据进行加密来保证其安全性，而针对敏感程度高的接口，则需要通过数字证书来进行双向认证。

（4）认证和鉴权

接口认证的目的是防止接口被任意应用调用，正常情况下，接口应只允许被授权过的应用调用，通过API服务提供方下发的App_ID与AppSecret、数字证书、公私钥对组合可识别应用身份，认证之后，需要根据App_ID开放不同接口给应用，完成鉴权。

（5）API流量限制

API接口每天都会到收到大量的访问请求，但由于接口所承载的业务不同，被调用的频率也会不同，因此可以通过分析和监测API接口被访问和调用的频率来确保API接口未被攻击者攻击，一般来说被攻击的API接口与正常接口调用情况在频率和调用总数上面都会出现较为明显的差异，因此通过统计API接口被访问的情况，进行限流等方式可以防护API出现被攻击者攻击甚至是拒绝服务的情况。

云原生下的API安全

从2019年OWASP将API安全列为未来最受关注的十大安全问题以来，API安全受到了越来越多的关注，而在当前云原生化的浪潮下，IT从基础架构层、到上面的微服务业务层都会有很多标准或非标准的API，既充当外部与应用的访问入口，也充当应用内部服务间的访问入口，这也导致了API的数量急剧增加、调用异常频繁，这无疑加剧了安全风险。

从云原生架构下的API防御角度来说，第3节我们提到的防御策略已经能够解决绝大多数API安全威胁，但同时我们也面对着诸多的困难，比如：

• 微服务架构下，因内部不可见性，企业对API的识别和发现变得更为困难；
• 服务间调用更为频繁，通过API进行横向攻击变得比以前更为容易；
• 研发运维一体化，部分运维、管理账号API更易暴露在攻击者面前；
• 服务更加细分，攻防粒度也变得更细，大而全的规则不再适用，API的防御规则更需精细化。

以上的这些特点，都让我们的防御变得更为难做，不过好在当前微隔离、免疫防御、Micro WAF等技术也在不断涌现，这些新技术的出现，已经可以在很大程度上缓解这些新问题带来的风险。无论如何，攻防本质是人与人之间的博弈，人总会犯错，新技术的诞生必然会带来新的安全问题，而API的安全风险也在这轮新技术的浪潮下出现了一些新的特点，关于API的攻防对抗，也将不断持续。