CVE-2021-45232 分析 (APISIX 网关未授权访问)

文章首发于：

火线 Zone-云安全社区​zone.huoxian.cn/

背景

apisix 网关之前出过一个 dashboard api 未授权访问漏洞 [1]：因为访问下面两个接口不需要身份认证，所以可以利用这两个接口进行 rce。

在刚分析这个漏洞时，我有点困惑：

filter 目录下的代码看着像是"中间件"(或者叫"过滤器")的实现，而"中间件"应该是所有请求都会经过"中间件"的业务逻辑，那为什么访问上面的两个接口就没有经过 filter.AuthenticationMiddleware 中间件的认证逻辑呢？为什么访问其他接口就会经过 filter.AuthenticationMiddleware 中间件的认证逻辑呢？

虽然动态调试下个断点，就能看到函数调用流程，但是我还想知道"路由"和"中间件"从 web 框架层来看是怎么设计的。

apisix 项目用到了 gin 框架和 droplet 框架，本文记录我对这两个框架"路由"和"中间件"使用和设计的研究，以解决自己的疑惑。

分析

01.为什么其他接口就会经过 filter.AuthenticationMiddleware 中间件的逻辑?

"业务代码"可以使用"gin 框架提供的 Use 接口"注册中间件，比如下面这样

从上图中并没有看到 filter.AuthenticationMiddleware 中间件被注册，那么为什么其他接口就会经过 auth 中间件的逻辑？

比如 GET /apisix/admin/routes HTTP/1.1

答案在 droplet 库：apisix 通过 droplet 接口注册了 filter.AuthenticationMiddleware 中间件。

这样当访问/apisix/admin/routes 路径时，请求会经过 gin 框架注册的"中间件"、droplet 注册的"中间件"。

有一个不严谨的结论：上面的两张图中，handlers 和 mws 数组中的所有"函数"会被依次调用。

02.为什么

/apisix/admin/migrate/export 接口不会经过 filter.AuthenticationMiddleware 中间件的逻辑?

/apisix/admin/migrate/export 路由对应的"处理函数"并不是 wgin.Wraps 包装的，这样代码流程会不从 gin 框架转移到 droplet 框架。

对比可以看到/apisix/admin/routes 路由对应的"处理函数"是 wgin.Wraps 返回的，这样代码流程会从 gin 框架转移到 droplet 框架。

小结：gin 框架和 droplet 框架通过 wgin.Wraps 包装的 func(ctx *gin.Context)函数类型连接到了一起。

03.怎么修复的？

从这个 commit[2]中可以看到:

• gin 框架中

  
  

  filter.AuthenticationMiddleware 中间件被添加

• droplet 框架中

  
  

  filter.AuthenticationMiddleware 中间件被删除

总结

本文只零散地记录一小部分 gin 和 droplet 框架的内部逻辑，对 gin 路由和中间件实现有兴趣的可以看《gin 框架源码解析》[3]这篇文章。

在分析过程中感觉"实现一个 web 框架"非常需要"接口"或者"函数类型"，比如 net/http 和 gin 框架的连接、gin 框架和 droplet 框架的连接，都是依靠"接口"或者"函数类型"来通信。

参考链接：

[1]https://apisix.apache.org/zh/blog/2021/12/28/dashboard-cve-2021-45232/

[2]https://github.com/apache/apisix-dashboard/commit/b565f7cd090e9ee2043fbb726fbaae01737f83cd

[3]https://www.liwenzhou.com/posts/Go/read_gin_sourcecode/

[4]漏洞分析：

https://mp.weixin.qq.com/s/WEfuVQkhvM6k-xQH0uyNXg