APISIX 安全评估教学文档

1. 背景介绍

APISIX 是一个动态、实时、高性能的 API 网关，提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。本文档基于对 APISIX 的安全评估过程，详细分析其安全架构和潜在风险点。

2. APISIX 系统组件分析

APISIX 项目包含多个子系统：

1. 网关核心 - 主要流量处理组件
2. Dashboard - 管理界面
3. Ingress 控制器 - Kubernetes 集成组件
4. 各种 SDK - 客户端工具

评估重点：网关核心和 Dashboard 是主要安全评估对象，SDK 攻击场景有限，Ingress 控制器需要结合 Kubernetes 网络评估。

3. 网关核心安全评估

3.1 网关核心模块划分

网关核心有三个关键模块：

1. 插件系统 - 功能扩展点
2. Admin API - 管理接口
3. Control API - 控制接口

3.2 Admin API 安全分析

认证机制

• 使用硬编码的 token 进行认证
• 已知问题：默认密钥问题(CVE-2020-13945)
• 官方态度：认为这是预期行为，不打算修复

鉴权机制

• 两种角色设计：
  • Viewer 角色：仅允许 GET 方法
  • 非 Viewer 角色：拥有完整权限

3.3 Control API 安全分析

安全特性

1. 默认仅在本地监听端口
2. 与插件无关的 Control API 只有"读信息"功能，风险较低

潜在风险

• 插件创建的 Control API 是潜在攻击面
• 需要审计插件创建的 Control API 端点

4. 插件系统安全评估

4.1 插件安全概况

• 插件默认不开启
• 历史漏洞主要集中在此模块
• 是安全评估的重点区域

4.2 CVE-2022-25757 漏洞分析

漏洞背景

• 影响模块：request-validation 插件
• 功能：检查 HTTP 请求头和 BODY 内容，不符合规则则阻止请求转发

漏洞原理

1. JSON 解析差异：

   • request-validation 插件使用 cjson.safe 库
   • 对于重复键值的 JSON，cjson.safe 取最后面的值
   • 许多流行库(如 gojay)会取最前面的值

2. 绕过示例：

   {"string_payload":"","string_payload":"1111"}
   

   • request-validation 解析为 string_payload="1111"
   • 上游服务可能解析为 string_payload=""

3. 配置示例：

   curl http://127.0.0.1:9080/apisix/admin/routes/10 \
   -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
   -X PUT -d '
   {
     "uri": "/10",
     "plugins": {
       "request-validation": {
         "body_schema": {
           "type": "object",
           "required": ["string_payload"],
           "properties": {
             "string_payload": {
               "type": "string",
               "minLength": 1,
               "maxLength": 32
             }
           }
         }
       }
     },
     "upstream": {
       "type": "roundrobin",
       "nodes": {
         "192.168.2.189:8888": 1
       }
     }
   }'
   

影响范围

• 任何使用 request-validation 插件且上游服务使用不同 JSON 解析库的场景
• 已知存在解析差异的库：
  • gojay (Go)
  • 其他根据 JSON 互操作性漏洞 中列出的库

验证代码示例 (Go)

package main

import "github.com/francoispqt/gojay"

type user struct {
    id    int
    name  string
    email string
}

func (u *user) UnmarshalJSONObject(dec *gojay.Decoder, key string) error {
    switch key {
    case "id":
        return dec.Int(&u.id)
    case "name":
        return dec.String(&u.name)
    case "email":
        return dec.String(&u.email)
    }
    return nil
}

func (u *user) NKeys() int {
    return 3
}

func main() {
    u := &user{}
    d := []byte(`{"id":1,"name":"gojay","email":"gojay@email.com"},"name":"gojay2"`)
    err := gojay.UnmarshalJSONObject(d, u)
    if err != nil {
        //log.Fatal(err)
    }
    println(u.name); // 输出 gojay 而非 gojay2
}

5. 安全评估方法论

5.1 评估思路框架

1. 攻击面识别

   • 系统组件划分
   • 接口分类
   • 功能模块分析

2. API 安全评估重点

   • 身份认证机制
   • 权限控制设计
   • 接口暴露范围

3. 插件安全评估重点

   • 业务逻辑漏洞
   • 输入验证缺陷
   • 与其他组件的交互

4. OpenResty 配置评估

   • 自定义 API 端点
   • 监听范围控制
   • 访问限制配置

5.2 特别建议

APISIX 的插件机制结合 OpenResty 的高性能，非常适合作为 WAF (Web 应用防火墙) 架构的基础，建议：

• 开发安全专用插件
• 建立插件安全审计流程
• 实现细粒度的访问控制

6. 总结与建议

6.1 已发现风险总结

1. Admin API 硬编码 token
2. Control API 潜在暴露风险
3. 插件系统 JSON 解析不一致漏洞(CVE-2022-25757)

6.2 加固建议

1. Admin API：

   • 强制修改默认 token
   • 实现 IP 访问限制
   • 考虑增加多因素认证

2. Control API：

   • 保持默认本地监听
   • 审计插件创建的 Control API
   • 添加必要的认证机制

3. 插件系统：

   • 严格审核第三方插件
   • 实现 JSON 解析一致性检查
   • 建立插件安全开发规范

4. 整体架构：

   • 实施最小权限原则
   • 定期安全审计
   • 监控关键组件更新

通过系统性的安全评估和持续的安全加固，可以显著提升 APISIX 在复杂环境中的安全性。