很多人使用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漏洞内容请搜索Devmax以前的文章或继续浏览下面的相关文章希望大家以后多多支持Devmax！