dsh-plugin-trust-audit

只读审计：DSH 端口上插件的 HTTP 路由，是否真的做了鉴权栅栏。

安装

# 从 GitHub Release 直链安装（不需要 npm 账号，不需要 git）
dsh plugin --profile <你的profile> add https://github.com/Anguis-L/dsh-plugin-trust-audit/releases/download/v0.1.0/dsh-plugin-trust-audit-0.1.0.tgz

装完重启一次 dsh（bundle 层要重启才组装），然后在会话里直接让 agent 调用 plugin_trust_audit。

为什么需要它

插件可以在浏览器 HTTP 载体上注册自己的前缀，而路由分发是最长前缀优先。一个比内核 /api 更长的插件前缀，会先于内核自己的准入检查执行 —— 于是"这条路由是否需要凭据"完全取决于插件自己，而社区里的两个样本结论相反：

实现	无凭据回环请求
dsh-our-free-model（用 connection.requestRejection）	401 已拦
dsh-bili-scroll 2.0.4（只有结构化栅栏）	200 放行

这个差别从外面看不出来 —— 插件目录里没有任何字段告诉你装的是哪一种。本插件把它变成可测量的。

判定口径

对每个候选路径发三组只读 GET 探测，每组回答不同的问题：

探测	头	回答什么
无凭据	无	裸奔的调用者能不能拿到数据
跨端口 Origin	Origin: http://127.0.0.1:65535	本机别的端口上的页面能不能驱动它（只比主机名、不比端口时会放行）
跨站 Origin	Origin: https://example.invalid	外部网页能不能驱动它

判定：

状态码	判定	含义
401 / 403	fenced	栅栏生效
2xx	open	无鉴权可达
404	absent	没注册路由，不构成风险
其它 / 超时 / 连不上	unknown	不等于安全

unknown 是三值判定的关键：把"判不了"糊成"安全"，是这里唯一真正危险的结果。

⚠️ 关于 absent 的一个实测坑

在真实宿主上测过：一条没被任何插件注册的路径，比如 /api/nonexistent-xyz，返回的是 401 而不是 404 —— 因为内核自己的 /api 前缀先接住了它。

所以：absent 在实践中很少出现；一条你以为"没注册"却返回 401 的路径，大概率是内核答的，不是插件栅栏生效。

因此判定描述的是该端口在该路径上的可观测行为，它不把响应归属到某个具体插件。要判断"这是不是插件栅栏"，需要结合该插件源码里是否真的做了 connection.requestRejection。

它自己不开任何 HTTP 路由

一个审计工具如果自己开了个裸奔的接口，就是它存在的意义本身的笑话。所以本插件只注册一个 Host 工具，没有 webServer.register。

只读

只发 GET，从不发写请求，所以审计不会改变它正在检查的状态。

用法

plugin_trust_audit()                                  # 审计当前 webServer 的回环地址
plugin_trust_audit({ origin: 'http://127.0.0.1:61782' })
plugin_trust_audit({ paths: ['/api/my-plugin/config'] })

只审计回环地址。对它机地址发起探测属于未授权扫描，本工具不做。

局限

判定基于响应状态码，不构成完整安全审计：它不能证明一条返回 401 的路由内部没有别的洞，也不能发现只在特定方法/参数下才触发的问题。