解析Nacos的API居然存在这么严重的漏洞

这篇文章主要介绍了Nacos的API居然存在这么严重的漏洞,Nacos为我们提供了大量API，但是这些API默认是没有开启认证的，直接可以访问，针对于这一点我们也都可以去验证一下,本文给大家详细讲解，感兴趣的朋友跟随小编一起看看吧

很多人使用Nacos其实并没有真正的去读过官网，以至于忽视了很多重要的细节，Nacos为我们提供了大量API，但是这些API默认是没有开启认证的，直接可以访问，针对于这一点我们也都可以去验证一下。下面我提供了两个调用示例供大家参考，基于这一点Nacos登录页也明确提示Nacos部署到内网，不要部署到公网，但是对于没真正了解过Nacos，压根也不知道有这个API，也不知道有开启授权这回事，所以也就意识不到这个API暴露出去后果到底有多么严重！

官网API：https://nacos.io/zh-cn/docs/open-api.html

仔细看我们下载的nacos的登录页面，有一个特别大的红字，内部系统，不可暴露到公网。所以nacos一旦部署在公网，风险非常大！

一、调用API示例

1.1. 示例一：获取配置

curl -X GET "http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=nacos-config-client-dev-yaml&group=DEFAULT_GROUP"

如下配置是我们要获取的配置：

开始访问：

会发现直接通过API就可以拿到，而且API没有任何认证，我认为这是一个很大的问题，那也就是意味着只要我知道你Nacos部署的地址以及端口，我就可以拿到你的配置。

我们有时候会往nacos当中存储一些数据库相关信息，一旦被盗窃，后果不堪设想。当然还好获取配置的API当中没有namespace参数，他只能查看public的。但是对于服务发现相关的API还有命名空间相关API他是提供了namespace参数的。

1.2. 示例二：删除命名空间

这里我专门创建了一个test命名空间，并且空间还有配置文件。

直接调用会惊讶的发现，竟然可以删除成功，而且还没有携带任何token什么的。

curl -X DELETE "http://localhost:8848/nacos/v1/console/namespaces" -d "namespaceId=test"

然后再去查看会发现test命名空间已经没有了。

这个问题就比较严重了，要知道我们系统当中都会依赖配置文件，一旦配置文件都被人删除了，后果是什么应该就不用我说了吧。

1.3. 示例三：获取登录用户信息

http://127.0.0.1:8848/nacos/v1/auth/users/?pageNo=1&pageSize=9

1.4. Nacos及时响应此问题

bug描述：https://github.com/advisories/GHSA-36hp-jr8h-556f
Nacos官网声明在2021年一月份发布的1.4.1版本修复了此问题：https://github.com/alibaba/nacos/pull/4703

在Nacos低版本当中，如上确实是一个bug，但是后来呢，Nacos针对于此也特意加了一个开关，用来控制是否鉴权。

不管怎么说，我们一定要尽量用最新的版本，因为Nacos其实版本之间变化相对来说没那么大，就算升级版本也很少会影响到我们自己的代码。

二、服务端如何开启鉴权？

官网介绍：https://nacos.io/zh-cn/docs/auth.html

官网给我们提供了Docker环境以及非Docker环境开启鉴权的方式。

非Docker环境直接修改application.properties当中的如下参数：

### If turn on auth system:
nacos.core.auth.enabled=true

注意：非Docker环境 鉴权开关是修改之后立马生效的，不需要重启服务端。

Docker环境直接启动命令当中添加如下参数即可：

-env NACOS_AUTH_ENABLE=true

开启后再访问API直接会403！

如果再想访问API需要先访问登录接口，获取到token，然后将token携带到参数访问即可，如下：

三、开启服务身份识别功能

这个主要是针对于Nacos集群而来的，开启鉴权功能后，服务端之间的请求也会通过鉴权系统的影响。我理解的就是将每个集群的节点设置的identity.key和identity.value设置为一样的，这样就认为鉴权通过了。

到此这篇关于Nacos的API居然存在这么严重的漏洞的文章就介绍到这了,更多相关Nacos API漏洞内容请搜索编程学习网以前的文章希望大家以后多多支持编程学习网！