APISIX 安全评估
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了APISIX 安全评估相关的知识，希望对你有一定的参考价值。
参考技术A 文章首发于火线Zone： https://zone.huoxian.cn/?sort=newest有大佬已经对 apisix攻击面 做过总结。
本文记录一下自己之前的评估过程。
首先我需要知道要评估啥，就像搞渗透时，我得先知道攻击面在哪里。
根据文档，可以知道apisix项目包括很多系统，包括：
sdk即使有漏洞，攻击场景也感觉有限，所以没有评估。
"ingress控制器"需要结合k8s中的网络来做评估，因为时间有限，所以只是粗略看了一下。
我主要看了网关和dashboard两个系统。
从文档上很容易看出来，网关有三个重要的模块：
对于api来说，首先要检查的是"身份认证"和"鉴权"这两个安全措施。
apisix历史漏洞绝大部分都出现在插件中，所以插件属于"漏洞重灾区"。
admin api实现如下：
control api是没有身份认证的，但是有两个点限制了攻击：
插件创建的control api是一个潜在的攻击面，不过我没找到啥漏洞。
因为插件默认都是不开启的，所以虽然它是重灾区，但是我并没有投入过多精力去审计。
不过在这里确实发现了一个安全问题，报告给官方后，分配了 CVE-2022-25757 。
下面来说一下这个安全问题。
request-validation插件可以检查HTTP请求头和BODY内容，当不符合用户配置的规则时，请求就不会转发到上游。
比如用户按照如下规则配置时，body_schema限制请求中必须要有string_payload参数，并且是字符串类型，长度在1到32字节之间。
但是恶意用户发送如下请求时，有可能绕过限制
request-validation.lua中使用cjson.safe库解析字符串为json对象，对于带有"重复键值"的json，它会取最后面的值。比如 "string_payload":"","string_payload":"1111" ，request-validation插件会认为string_payload="1111"。
但是有很多流行的库，对于带有"重复键值"的json，它会取最前面的值，因此 "string_payload":"","string_payload":"1111" 会被认为string_payload=""。
因此request-validation插件和上游服务在解析json时可能存在差异性，所以会导致限制被绕过
根据 https://bishopfox.com/blog/json-interoperability-vulnerabilities 文章，可以知道最起码以下库和request-validation插件在解析"重复键值json"时存在差异。
选取其中的gojay库做了验证，程序打印gojay而不是gojay2
评估思路比较简单：
openresty配置中的api也是攻击面，下一篇再写。
Apache Apisix 安全漏洞(CVE-2020-13945)
文章目录
0x01 漏洞介绍
Apache Apisix是Apache基金会的一个云原生的微服务API网关服务。该软件基于OpenResty 和 etcd来实现，具备动态路由和插件热加载，适合微服务体系下的 API 管理。Apache APISIX存在安全漏洞，该漏洞源于用户启用了管理API并删除了管理API访问IP限制规则。最终，默认令牌被允许访问APISIX管理数据- 在 Apache APISIX 中，用户启用了管理 API 并删除了管理 API 访问 IP 限制规则。最终，允许默认令牌访问 APISIX 管理数据。
0x02 影响版本
- Apache APISIX 1.2、1.3、1.4、1.5。
以上是关于APISIX 安全评估的主要内容，如果未能解决你的问题，请参考以下文章