API接口的越权漏洞风险都有哪些?




微型服务是一种开发软件的体系结构和组织方式,其中软件包括一些中小型的单独服务,它们根

据明确定义的API进行通信。每一个中小型单独团队负责这些服务;采用UNIX设计理念,每一个

服务只做一件事情,而且是一个可以单独开发和实施的松耦合无状态服务。


 
微型服务有两个关键特征:自主性、专门性,它们的优点是敏捷、可伸缩、易于实施、技术自由

、代码可重复使用、有弹性[1]。

 
由上面的描述可以看出,微服务更多的是一种方法,而微服务体系结构是实践微服务的一个具体

实现,不同的厂商,不同的开发人员在实现微服务时会有不同,大概体系结构如下图[2]。这样,

开发人员就可以集中精力开发自己负责的服务、解决系统复杂性、可单独实施、适合DevOps开

发过程等等,难怪现在几乎所有人都使用微服务。不过,不管是哪种技术,其好处越多,其负面

影响就越大。
第二,微服务的接入困难。
 
 
将应用拆分为多个微服务,这样,原来单个架构下的权限体系就不能符合微服务的鉴权规定,

每一个微服务都需要自己的API进行权限控制,需要对接账号体系,明确哪些角色有权限访问

;以及来自服务之间的调用等等。这样的话,不管是根据session方案还是token方案,都需要

开发去维护这个权限系统,然后问题就来了。商业产品在后面追,各种发布封网在前面拦,往

往会为了完成商业功能而取掉部分权限,或者不同的开发同学对鉴权的理解不一致,甚至认为

有没有权利登陆就认为已经完成了权限检查。
 
 
 
由于这种类型的API越来越多,将会经常出现类似的安全问题,尤其是未授权访问此类低层漏

洞。这一方面是为了管理杂乱无章的API调用关系,一方面是为了解决上面提到的风险,微服

务调用需要一个统一控制的部分,即APIGatedway。难道现在就没有越权漏洞了吗?创意很好

,但是现实往往会给人留下不好的印象,而Gateway的架构缺陷常常会带来更大的风险。
 
 
PAIGatedway只是一个入口
 
这种网关通常只起一条路由的作用,它可能只具有一个域名和简单的路由转发功能,将同一部

分业务的API根据同一域名开发出来,把API的权限校验都交给相应的开发人员去做,当出现未

经授权的访问漏洞时,双方就开始扯皮,这种权限校验难道不该做吗?尤其当业务规模特别大

的时候,数以千计的API可以被访问,这可真是一场灾难~。
 
 
根据黑名单来控制APIGatedway的访问。有时需要控制一部分API开放公网另一部分未开放,

有时需要控制一部分API可公开访问,等等。当处理这些需求时,许多开发都将APIGatedway

设计为黑名单模式,比如,blackstring中添加了无法外部开发的API,或者,需要进行菜单访问

控制的API,这些API都需要主动配置。在字面上,这似乎没什么问题,合情又合理,但回到人

性中,人是健忘的,怕麻烦,因此往往会导致内部API忘记配置blackstring开放公共网络或忘记

配置权限菜单造成未经授权访问漏洞。
分享: