哪吒监控路径穿越漏洞分析：一个 `/dashboard..` 拿下全站 JWT 密钥

问题出在哪#

Nezha Dashboard 在处理静态资源时，为了隔离不同模板目录，在路由层做了一个前缀校验——检查请求路径是否以 /dashboard 开头。只允许通过前缀检查的请求进入模板渲染的逻辑。

逻辑本身没问题，但实现上踩了一个经典坑：前缀比对没有做路径段边界检查。

Go 的 strings.HasPrefix 只判断字符前缀，不关心你后面跟的是 /、..、还是别的什么。于是攻击者构造出这样的路径：

1
/dashboard../data/config.yaml

拆开看：

• /dashboard —— 通过了前缀检查，“合法”
• ../ —— 往上跳一层，跳出模板目录
• data/config.yaml —— 命中 Dashboard 的工作目录，拿到配置文件

每一步都不违反代码的字面逻辑，但组合起来就把目录限制彻底穿透了。

用伪代码理解这个缺陷：

1
// 原始逻辑（有漏洞）
2
if strings.HasPrefix(r.URL.Path, "/dashboard") {
3
    // 渲染模板文件...
4
    tmpl.Execute(w, filepath.Join(tmplRoot, r.URL.Path))
5
}
6

7
// 实际解析：
8
// r.URL.Path = "/dashboard../data/config.yaml"
9
// HasPrefix 返回 true ← 漏洞点
10
// filepath.Join(tmplRoot, "/dashboard../data/config.yaml")
11
//   → tmplRoot + "../data/config.yaml"
12
//   → 逃逸成功

filepath.Join 会对 .. 做规范化处理，于是路径就从模板目录往上跳了一级，进入了 Dashboard 的工作目录——配置文件、数据库、日志，全在射程范围内。

为什么说这个洞”严重”#

大部分路径穿越漏洞能读文件，但读出来的是 HTML、JS、CSS 或者没什么用的系统文件。这个洞读的是 config.yaml，里面躺着什么？

1
jwt_secret_key: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

JWT 签名密钥是整个认证体系的命根子。有了它，攻击者可以：

1. 伪造任意用户 Token——用泄露的密钥签名一个管理员身份的 JWT，面板直接认你为 admin
2. 劫持所有 Agent 通信——Agent 与 Dashboard 之间的 gRPC 通信如果也用这套 JWT 做鉴权，伪造 Token 就能下发任意指令
3. 持久化控制——密钥轮换需要重启服务且所有 Agent 重连，运维窗口期往往长达数天，这给了攻击者充裕的时间

CVSS 9.1 的评分拆解开来看：

• AV（网络可达）—— HTTP 端口默认暴露
• AC（复杂度低）—— 一个 GET 请求即可
• PR（无需认证）—— 匿名访问
• UI（无需用户交互）—— 纯自动化
• C / I（机密性高 / 完整性高）—— 拿到密钥等于拿到一切

升级#

直接升级到 Nezha v2.0.13 或更高版本。官方补丁将前缀检查改为了段感知（segment-aware）的路径校验——不再是简单的字符串前缀匹配，而是确保路径被正确规范化后不会逃逸出模板根目录。

临时缓解#

如果暂时无法升级，推荐在反向代理层做路径规范化防护。以 Nginx 为例：

1
location /dashboard {
2
    # 规范化 URI，折叠 ../ 等目录回溯符
3
    set $safe_uri $uri;
4
    if ($uri ~ \.\./) {
5
        return 403;
6
    }
7
    proxy_pass http://nezha_dashboard;
8
}

但由于 Go 的 filepath.Join 在服务端也会做规范化，仅靠反向代理层的黑名单拦截存在绕过风险，升级才是正道。