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开放公共网络或忘记

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